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I.  Introduction  and  Project  Goals 

Information  technology  changes  over  the  past  5-10  years  have  altered  the  manner  in  which 
individuals  in  organizations  accomplish  their  work.  TTie  rapid  proliferation  of  mini  and  micro¬ 
computers  that  has  occurred  in  many  organizations  has  helped  to  make  end  user  computing  a 
reality.  This  decentralization  of  computing  power  has  permitted  organizational  members  to  learn 
and  apply  business  software  tools  such  as  spreadsheets,  databases,  desktop  publishing,  graphics, 
word  processing,  etc.  to  the  completion  of  work  related  tasks,  usually  in  a  more  efficient  and 
effective  manner  than  the  way  in  which  such  tasks  were  accomplish^  in  the  past.  Indeed,  such 
business  software  has  helped  to  make  computing  an  increasingly  fundamental  part  of  many 
organizational  jobs.  One  interesting  corollary  associated  with  such  technology  changes  is  that 
increasing  amounts  of  work  are  stored  and  processed  primarily  on  the  microcomputer  (e.g.,  as 
when  all  relevant  data,  analyses,  documentation  fcH-  a  given  project  are  completely  "filed"  and 
accessed  on  the  computer  versus  a  paper-and-pencil  set  of  files). 

While  the  impact  of  information  technology  on  organizational  work  at  the  individual  level 
has  been  fairly  evident,  it  is  far  less  visible  at  the  group  level.  This  is  not  surprising  given  that  the 
implementation  and  use  of  such  technology  at  the  group  level  typically  depends  both  on  its 
establishment  and  use  at  the  individual  level-  an  occurrence  which  has  only  recently  taken  place- 
as  well  as  the  implementation  of  computer  netwenking  capabilities  linking  end  users  with  one 
another  as  well  as  with  corporate  computing  resources  (e.g.,  printers,  databases,  etc.).  Computer 
networking  capability,  which  now  appears  to  have  become  an  essential  part  of  most  organization's 
information  technology  picture,  is  also  a  very  recent  technological  change  for  many  organizations. 

The  manner  in  which  information  technology  can  be  used  to  affect  group  decision  making 
varies  considerably.  Dennis,  George,  Jessup,  Nunamaker,  &  Vogel  (1988)  provide  a  useful 
taxonomy  of  group  decision  support  systems  based  on  thr^  dimensions:  (3roup  Size  (small, 
large).  Group  Proximity  (multiple  individual  sites,  one  group  site,  multiple  group  sites),  and  Time 
Dispersion  (all  meet  at  one  time,  asynchronous  meetings).  Dennis,  et  al.  argue  that  there  are  six 
basic  categories  of  electronic  meeting  systems  (EMS)  l^t  can  be  used  synclmnously  or 
asynchronously.  This  is  illustrated  in  Figure  1. 


Insert  Figure  1  about  here. 


The  authors  note  that  the  most  common  form  of  an  organizational  meeting  is  one  where  a 
small  group  of  participants  meets  in  one  place  at  the  same  time.  Supporting  that  type  of  meeting 
has  been  the  focus  of  those  who  have  establishing  sophisticated  "Decision  Rooms"  and  developed 
appropriate  electronic  meeting  software  (e.g.,  PIXXSYS)  and  protocols  to  aid  group  decision 
m^ng  (e.g.,  Dennis,  George,  Jessup,  Nunamaker,  Vogel,  1988;  Vogel,  Nunamaker,  George, 
Dennis,  1988).  Here  the  ha^waie  and  software  technology  is  used  to  control  the  manner  in  which 
group  membm  interact  with  each  other  during  the  accomplishment  of  group  tasks  such  as  idea 
generation.  While  the  technology  usually  automates,  as  well  as  speeds  up,  some  group  processes 
(e.g.,  collection  and  recording  of  ideas  in  brainstorming),  it  also  permits  groups  to  "interact"  in 
ways  which  would  not  be  pmsible  without  the  technology  (e.g.,  the  concept  of  parallel  talk 
implemented  in  the  electronic  brainstoiming  module  of  PLEXSYS).  While  such  electronic  meeting 
facilities  and  tools  are  indeed  useful,  they  are  also  expensive  to  set  up,  can  only  be  used  by  me 
group  at  a  time,  and  require  the  physical  presence  of  all  group  membm.  Thus,  this  type  of  group 
decision  support  is  likely  to  benefit  only  a  restricted  sample  o(  work  groups  that  exist  in 
organizations. 
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Another  example  of  how  information  technology  can  impact  the  manner  in  which  groups  in 
organizations  work  is  evident  in  the  popularity  and  frequency  of  use  of  electronic  mail  systems 
which  usually  permit  the  sending  and  receiving  of  both  messages  as  well  as  files  through  the 
computer  network.  In  its  plain  vanilla  fesm,  such  E-mail  technology  acts  as  an  effective,  quicker 
substitute  for  overnight  mail  delivery  services  as  well  as  a  means  of  avoiding  “telephone  tag”  by 
asynchronously  conveying  messages  which  would  normally  be  delivered  via  telephone.  Since  E- 
mail  is  usually  implement^  with  computer  networking,  it  provides  a  common  groundwOTk  across 
organizations  for  supporting  collaborative  work  at  all  levels  in  organizations  through  computing 
technolo^.  In  the  Dennis,  et.  al.  framework,  this  would  correspond  to  the  "Local  Area  Decision 
Net"  environment  operating  in  asynchronous  fashion. 

We  believe  that  the  prevalence  of  computer-supported  distributed  team  wtM'k  in 
organizations  fitting  the  "Local  Area  Decision  Net"  classification  will  increase  markedly  in 
organizations,  especially  for  those  whose  members  (and  associated  skills  and  abilities)  are 
dispersed  over  geographically  diverse  sites  (e.g.,  regional  offices)  or  whose  work  requires  them  to 
be  geographically  separated  (e.g.,  military  assault  teams).  Moreover,  we  believe  that  the  recent 
development  of  networidng  software  that  permits  screen,  as  well  as  computer,  sharing  strongly 
enhances  the  viability  of  successfully  executing  team  work  in  a  distributed  fashion  since  it  has  the 
potential  for  making  synchronous  distributed  team  work  a  viable  technique.  Yet,  while  such 
information  technology  is  available,  systematic  knowledge  about  how  distributed  groups  may 
actually  use  (or  should  use)  computer  and  communication  technology  to  best  accomplish  their 
work  is  regrettably  scarce.  This  lack  of  relevant  behavioral  knowl^ge  about  how  individuals  and 
groups  respond  to  advanced  information  technology  in  turn  hinders  the  development  of  appropriate 
groupware  and  guidelines  for  computer-supported  distributed  team  work. 

(Ilorrespondingly,  the  research  to  be  reported  focused  directly  on  the  viability  of  distributed, 
interacting,  computer-supported  team  work  and  the  factors  that  might  impact  the  effective 
performance  of  such  groups.  We  should  note  that  by  "distributed"  we  are  referring  to  groups 
whose  members  are  geographically  separated,  by  "computer-supported"  we  are  referring  to 
software  that  permits  group  members  to  "screen  share"  as  well  as  exchange  files,  and  by 
"interacting"  we  are  referring  to  groups  wra-king  synchronously  on  their  task.  As  a  starting  point, 
we  will  first  consider  the  concept  of  dstributed  groups  more  closely.  Then  we  will  examine 
several  different  configurations  of  distributed  team  work  and  the  restrictions  they  impose  on  group 
process  (relative  to  face-to-face  groups),  focus  cm  the  configuration  that  we  will  use  as  the  basis 
for  our  investigations  and  summarize  the  purpose  and  goals  of  this  research. 

Distributed  Team  Work 

The  concept  of  distributed  team  work  is  not  a  new  one;  pressures  for  woricing  in  a 
distributed  fashion  cited  earlier  have  existed  for  quite  some  time.  However,  for  groups  to  be  able 
to  work  in  a  distributed,  as  opposed  to  face-to-face,  fashion,  there  must  be  some  provision  for 
providing  communications  between  the  members  of  die  group.  We  can  better  understand  different 
means  of  suppcHting  distributed  group  performance  by  considering  the  nature  of  communications 
that  (xxur  in  ftu;e-to-face  groups  and  dim  consider  how  different  alternative  forms  of  supporting 
distributed  team  work  compare  to  that  standard 

Face-to-face  group  interaction  provides  group  members  with  a  rich  array  of  information. 
The  "bandwidth"  of  communication  is  wide  and  includes  bodi  audito^  as  well  as  visual  channels 
of  information.  It  is  useful  to  further  distinguish  two  informational  signals  within  each  of  these 
channels:  task  and  social.  Task  information  focuses  on  objective  information  concerning  the 
operation  and  execution  of  the  task  required  for  its  completion.  Example  of  task  information 
would  be:  dimensions  of  a  particular  building  design,  budget  figures  for  a  given  project,  the 
particular  form  of  a  forecasting  model  used  to  generate  financial  predictions,  number  of  man  hours 
required  to  complete  a  given  project,  etc.  Thus,  task  information  would  not  bear  directly  on  social 
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relations  between  group  members,  cohesiveness,  esprit  de  corps,  satisfaction,  or  any  other 
measure  that  has  affect  as  its  primary  component.  Instead,  we  would  characterize  information 
relevant  to  affective  concerns  as  being  social  in  nature.  For  example,  statements  of  liking  or  dislike 
for  other  group  members,  denigration  of  the  efforts  or  abilities  of  other  group  members,  tone  of 
voice  or  visual  gestures  indicating  disapproval  or  approval,  arc  all  examples  of  communications 
that  carry  a  great  deal  of  social  information. 

Since  successful  group  task  performance  will  depend  on  the  extent  to  which  the  demands 
imposed  by  the  task  (e.g.,  Hackman,  1987,  Steiner,  1972)  are  met  by  the  group,  the  relative 
effectiveness  of  different  forms  of  technologically  supporting  distributed  team  work  in  facilitating 
group  performance  will  likely  depend  on  the  characteristics  of  the  task  facing  the  ^up.  For 
example,  if  a  given  task  actu^ly  requires  very  little  in  the  way  of  harmonious  relations  among 
group  members  (i.e.,  the  social  demands  of  the  task  are  low),  then  a  relative  lack  of  social 
information  should  not  be  detrimental  to  successful  group  p^ormance  of  the  task.  On  the  other 
hand,  if  the  group  task  imposes  strong  interdependencies  anaong  its  members  for  successful 
completion,  then  a  wider  bandwidth  of  information  (i.e.,  social  as  well  as  task)  may  be  required 
for  its  successful  completion.  We  can  illustrate  some  of  these  ideas  by  considering  some  forms  of 
distributed  team  work  that  are  now  occurring. 

Teleconferencing.  Perhaps  the  most  prevalent  form  of  distributed  team  work  would  be 
teleconferencing  due  to  its  widespread  availability  (phones  are  standard  equipment)  and  relative 
inexpensiveness  (no  other  additional  equipment  is  required).  In  this  case,  communications  among 
the  distributed  group  members  are  synchronous  with  only  the  audio  channel  being  open.  Task 
information  (i.e.,  analyses,  documents,  etc.)  bearing  directly  on  the  purpose  of  this  meeting  will 
usually  have  been  distributed  earlier  to  group  members.  In  this  type  of  meeting,  the  auditory 
channel  is  open  and  allows  group  members  to  verbally  exchange  task  and  sociSi  information. 
Paralinguistic  cues  (i.e.,  pauses,  inflection,  etc.)  may  also  be  conveyed  and  perceived.  Details  and 
potentid  points  of  ambi^ity  may  also  be  clarified  by  the  synchronous  nature  of  communication. 
What  is  missing  in  this  case  is  the  visual  channel  of  information  pertaining  both  to  the  task  as  well 
as  to  social  considerations.  If  the  task  is  one  which  has  a  strong  visual  component  to  it  (e.g., 
illustrations  of  potential  new  product  designs,  information  displayed  in  graphical  form),  then 
teleconferencing  may  not  be  able  to  adequately  meet  the  demands  of  the  task  and  result  in  poorer 
performance.  Similarly,  if  a  given  task  invokes  a  considerable  degree  of  affect  on  the  part  of  group 
members  (e.g.,  deals  with  important  values  or  resources  about  which  there  is  initial  disagreement, 
requires  cooperaticr.  anrong  groups  who  have  been  rivals,  etc.),  then  the  missing  visual  channel 
prevents  group  members  from  picking  up  non-verbal  information  (e.g.,  looks  of  disgust,  lack  of 
eye  contact,  body  position,  etc.)  which  may  be  crucial  in  interpreting  other  group  member's 
positions  and  avoiding  "misunderstandings"  which  may  detrimentally  affect  subsequent  group 
interaction  and  performance. 

Video-conferencing.  One  means  of  restoring  the  visual  channel  is  to  move  from 
teleconferencing  to  videoconferencing.  Here  distribute  group  members  can  both  see  as  well  as 
hear  each  other.  While  this  type  of  technique  does  largely  succeed  in  restoring  the  audio  and  visual 
channels  of  information  to  that  of  a  face-to-face  group,  the  technology  require  to  do  this  in-house 
is  costly  and  still  requires  group  members  to  travel  to  ^eir  respective  video  conferencing  studios 
for  the  ^oup  meeting.  However,  the  visual  demands  of  a  task  may  make  this  the  only  viable 
alternative  to  a  face-to-face  meeting.  For  example,  in  order  for  store  buyers  to  evaluate  the  lines  of 
clothing  they  would  like  to  purchase  from  their  suppliers  the  buyers  need  to  evaluate  the  clothing  as 
it  would  appear  on  dynamic  (in  motion)  as  oppos^  to  static  models.  In  this  way  buyers  can  avoid 
purchasing  styles  that  may  look  good  on  paper  but  do  not  hang  or  move  nicely  on  customers. 
Similarly,  if  the  task  demands  a  great  deal  of  consensus  from  group  members  and  a  strong  sense  of 
commitment,  then  the  use  of  video  conferencing  allows  one  to  better  pick  up  relevant  social 
information  as  well  as  to  better  convey  affective  concerns. 
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E-mail.  E-mail  is  another  form  of  supporting  distributed  groups  that  has  become  viable 
with  the  implementation  of  computing  technology.  E-mail  is  asynchronous  in  nature  with  both  the 
auditory  and  visual  channels  (with  the  exception  of  the  mail  message  itself)  absent.  As  such,  the 
bandwidth  of  communication  possible  with  E-mail  is  very  narrow.  For  the  most  part.  E-mail  is 
most  appropriate  for  relatively  simple,  routine  tasks  which  are  relatively  unambiguous,  do  not 
invoke  strong  affective  feelings  and  conflict,  do  not  impose  a  great  deal  of  interdependencies 
among  group  members,  and  are  not  on  a  particularly  tight  time  frame.  When  the  demands  of  the 
group  task  extend  beyond  those  limits,  then  the  ackquacy  of  E-mail  for  facilitating  distributed 
group  performance  is  likely  to  be  low.  However,  the  relatively  low  cost  of  E-mail,  given  that 
computing  and  networking  capabilities  have  alre^y  been  implemented,  and  its  relative  ease  of  use 
makes  it  a  popular  form  of  support  for  distributed  group  members. 

Teleconferencing  with  Screen  Sharing.  Another  form  of  supporting  distributed 
groups  is  emerging  out  of  recent  software  that  is  (ksigned  to  allow  individuals  on  a  computer 
network  to  both  share  their  computers  as  well  as  their  screen  displays.  The  latter  capabilities  allow 
distributed  group  members  to  show  others  (by  allowing  them  to  observe  their  computer  screen) 
what  they  are  doing  by  bringing  up  relevant  task  information  stored  on  their  computer  relevant  to 
the  group  project.  Control  of  one's  computer  may  also  be  passed  to  other  group  members, 
allowing  them  to  demonstrate  or  change  things  drreedy  on  the  host’s  computer  (e.g.,  changing  the 
values  of  a  what-if  model  to  see  what  happens,  drawing  an  illustration  or  graph  to  go  with  a  final 
report,  etc.).  Taken  in  conjunction  with  teleconferencing,  this  form  of  supporting  distributed 
group  members  succeeds  in  restoring  the  auditory  channel  of  information  and  partially  restoring  the 
visu^  channel  by  allowing  visual  task  informatitm  to  be  conveyed  (presuming  that  relevant  task 
information  is  stored  on  individual  group  member’s  computers).  TTiis  type  of  process  is 
synchronous  in  nature  and  permits  the  exchange  of  relevant  task  documents  among  group  members 
either  through  the  use  of  existing  E-mail  systems  or  through  the  file  exchange  capabilities  built  in  to 
the  screen  sharing  software  directly.  Given  the  prior  existence  of  computers  and  networking 
capabilities,  the  addition  of  this  screen  sharing  technology  is  inexpensive. 

We  believe  that  the  "teleconferencing  with  screen  sharing"  fcam  of  distributed  team  work  is 
one  that  will  strongly  enhance  the  abilities  of  distributed  groups  to  accomplish  a  wide  variety  of 
tasks  due  to  its  increased  bandwidth  of  communication  (i.e.,  full  audio  channel,  visual  usk 
channel),  relative  case  of  use,  low  cost  to  group  members  (no  travel  beyond  their  office  computer), 
and  synchronous  nature  of  communication.  However,  the  lack  of  visual  non-verbal  information  is 
likely  to  have  a  detrimental  effect  on  tasks  that  exert  strong  social  demands  (e.g.,  potential  conflict 
problems,  problems  with  strong  interdependencies). 

P'lrpose  and  Goals 

The  purpose  of  the  work  outlined  in  this  report  is  to  develop,  implement,  and  pilot  test  a 
research  paradigm  for  systematically  examining  factors  that  may  impact  the  effectiveness  of 
computer-supported  distributed  team  work.  Within  this  gener^  pv^se,  we  had  two  goals.  First, 
we  wanted  to  establish  a  research  setting  where  we  could  study  the  factOTS  that  lead  to  effeaive 
distributed  computer-supported  team  work.  Second,  we  wanted  to  investigate  how  through  the 
use  of  commercially  available  software  and  hardware,  we  could  "patch-together"  computers  of 
different  architecture  and  operating  system  in  order  to  faciliute  computer-supported  distributed 
groups  working  under  varying  systems. 

The  remainder  of  this  report  will  be  in  ffve  sections.  First,  we  will  describe  the  equipment 
and  software  purchased  and  their  functions.  Then,  we  will  describe  the  development  of  the  task 
and  its  accompanying  software  development  which  was  essential  for  studying  group  processes  that 
are  relevant  for  the  United  States  Army  Information  Systems  Command  (USAISC).  Next,  we  will 
describe  and  evaluate  the  various  denxMistrations  of  con^uter-communication  that  we  tried.  This 
will  be  followed  by  a  description  of  the  expoimentation  that  we  conducted  on  4  groups  of  research 


Distributed  Computer  Supported  Team  Woik 

Page  9 

participants  who  worked  on  the  exjjerimental  task.  Finally,  we  will  give  some  recommendations 
concerning  future  research  and  practice. 

2.  Description  of  Activities  Leading  to  Goal  Accomplishment 

1..  inis  section  we  will  describe  the  hardware  and  software  acquired  to  fulfill  the  goals  of 
the  project,  the  configurations  of  distributed  groups  that  it  permitted  us  to  test,  and  the  development 
of  tlw  Allege  of  Management’s  Behavioral  Laboratory  into  a  computer-supported  distributed  team 
work  research  facility. 

Hardware  Acquisitions  and  Functions 

Macintosh  Systems.  Two  Macintosh  systems  were  acquired: 

1)  Mac  Bex  40HD,  Apple  Extended  Keyboard,  Memory  Upgrade  (to  5  MB),  Apple  Hi- 
Res  (jolor  MonittM*,  Apple  Extended  Video  Card 

2)  Mac  SE  20HD,  Apple  Extended  Keyboard,  Memory  Upgrade  (to  2.5  MB) 


The  purposes  of  these  systems  were:  1)  to  develop  the  task  software  (conducted  primarily 
on  the  Mac  Ilex  system  and  described  mtve  fully  in  Section  3  of  this  report),  2)  permit  Macintosh 
to  Macintosh  Timbuktu  Remote  connections  (see  configurations  subsection),  and  3)  permit 
Macintosh  to  Macintosh  Timbuktu  Network  connections. 

IBM  Systems.  Two  IBM  systems  were  acquired: 

1)  IBM  PS/2  70-121,  IBM  8513  Color  Monitor,  80387  Coprocessor,  Procom  1.2mb 
External  Drive,  Everex  2400/2  Internal  Modem,  Daystar  AppleTalk  Board 

2)  IBM  PS/2  80-111,  System  Board  Ram  Kit  80-11 1,  IBM  8513  Color  Monitor. 

The  purposes  of  these  systems  were:  1)  to  permit  remote  IBM  to  Macintosh  connectivity 
via  an  IBM  connected  to  an  AppleTalk  network,  2)  to  permit  IBM  connectivity  to  Macintosh 
network. 

Communications  Hardware.  The  following  communications  hardware  were  acquired* 

1)  Three  Hayes  V-Series  96(X)  baud  modems,  Hayes  V-Series  cable  for  IBM  (one  to  the 
Spelman  subcontractor). 

2)  Farallon  Phone  Net  Connectors  (6) 

3)  Miscellaneous  netwenking  materials  (e.g.,  phone  wire,  phone  wall  jacks  and  plugs, 
etc.). 

The  modems  were  acquired  to  facilitate  remote  Mac-to-Mac  and  IBM-to-Mac  distributed 
group  communications.  The  items  listed  in  2  &  3  were  used  to  install  networking  capability  in  the 
College  of  Management’s  Behavioral  Laboratory. 


Distributed  Ccunpuier  Supported  Team  Work 

Page  10 


Software  Acquisitions  and  Functions 

The  software  acquired  fw  this  project  can  be  broadly  classified  as  being  related  to  either 
task  developntent  or  communications. 

Task  Development  Software.  The  following  software  was  acquired  to  facilitate  the 
development  of  the  task  that  groups  would  be  working  on:  1)  SuperCard  (Silicon  Beach),  2) 
MacRecorder  (Farallon),  and  3)  ScrecnRccordcr  (Far^on). 

The  group  budget  cutting  task  was  developed  within  SupeiCatd,  an  object  oriented 
application  development  program  which  utilizes  the  SuperTalk  programming  language  (generally 
regarded  as  a  superset  of  Apple  Computer’s  HyperCard  HyperTalk  language).  Enhancements  in 
.SuperCard  over  HyperCard  ^at  led  to  its  selection  as  the  tool  for  developing  the  task  software  for 

this  p'oject  were: 

1 )  ability  to  have  multiple  windows  showing  at  the  same  time  on  a  screen 

2)  ability  to  fully  utilize  monitcas  larger  than  the  9”  standard  screen  on  the  Mac  Plus  and 
SE  line  (i.e.,  Mac  II  color  monitors,  full  page  displays,  etc.) 

3)  ability  to  construct  and  use  custom  menus  in  a  given  project 

4)  ability  to  have  multiple  windows  active  at  the  same  time  on  the  screen  (i.e.,  floating 
palettes) 

5)  ability  to  convert  HyperCard  stacks  to  SuperCard  projects 

6)  ability  to  generate  a  stand-alone  application 

The  MacRecorder  and  ScreenRecorder  software  were  both  acquired  to  facilitate  the 
development  of  the  initial  tutcmal  for  group  members  concerning  the  budget  software  and  how  to 
use  Timbuktu  to  screen  share  with  othw  group  members. 

The  MacRecorder  allows  one  to  digitally  record,  as  well  as  riKxlify,  soutkIs  recorded 
through  its  microphone.  These  sounds  can  then  be  built  into  an  applkadon  and  invoked  at 
appropriate  mcMnents  by  the  program.  Thus,  instructions  can  be  recorded  via  the  MacRecorder  and 
played  back  during  the  tutorial. 

The  ScreenRecorder  allows  one  to  create  a  “t^”  of  all  events  that  display  on  a  screen  at 
the  user’s  ^scretion.  Thus,  one  can  make  an  instructional  “movie”  that  demonstrates  ail  the  mouse 
moves  and  events  required  to  accon^lish  a  particular  task  (e.g.,  how  to  use  Timbuktu).  This  tape 
can  be  invoked  during  the  appropriate  moment  in  the  tutori^. 

Communications  Software.  The  following  conununications  software  were  acquired; 

1)  Farallon ’s  Timbuktu  Version  3.0  (4  copies) 

2)  Farallon’s  Timbuktu/Remote  (2  copies) 

Timbuktu  3.0.  The  Timbuktu  software  allows  group  members  on  a  network  to  exchange 
files  and  to  share  their  computers  with  other  members  on  the  network  in  either  an  “Observe  screen 
Only”  or  “Control”  mode  by  invoking  Timbuktu  (which  is  installed  as  a  desk  accessory  and,  thus. 
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available  at  any  time)  and  clicking  the  “On”  radio  button  for  guest  access.  All  Macintoshs  on  the 
network  that  allow  guests  are  listed  in  a  scroll  box  and  can  be  chosen  by  those  wishing  to  “visit”. 

In  the  “Observe  Only”  case,  the  group  member  acting  as  the  “host”  effectively  allows  any 
guest  to  “peer  over  his/her  shoulder”  and  see  exactly  what  he  sees  on  his/her  screen.  In  this  mode, 
guests  are  limited  to  only  one  action,  which  is  to  disconnect  from  the  host  (i.e.,  stop  observing) 
and  return  to  normal  operation  of  their  own  system. 

In  the  “Control”  mode,  group  members  —or  other  guests—  signing  on  to  the  “host” 
Macintosh  can  not  only  see  the  exact  display  of  the  host  machine,  but  can  also  remotely  control  all 
aspects  of  the  host.machine. 

Access  to  the  “host”  machine  is  controlled  by  a  password  system,  with  different  passwords 
for  different  levels  of  access.  The  screen  of  the  computer  being  observed  or  controlled  displays  an 
icon  in  the  right  hand  side  of  the  menu  bar  to  indicate  the  presence  of  a  guest  observer  (icon  of  a 
person  peering  over  the  comer  of  a  piece  of  paper)  or  guest  controller  (icon  of  a  hand).  In  all 
cases,  the  person  whose  system  is  being  observed  can  click  on  the  icon  and  choose  the  appropriate 
“disconnect”  guest  option  from  the  pull-down  menu.  If  so  desired,  the  host  can  also  make  him  or 
herself  unavailable  to  guests  by  clicking  the  “Off’  radio  button  for  guest  access  within  Timbuktu. 

The  initial  version  of  Timbuktu  that  we  acquired  was  version  2.01.  This  version  did  not 
provide  the  observer  with  a  separate  cursor  that  they  were  in  control  of  when  they  were  viewing 
another  person's  Mac  thus  malung  it  difficult  to  move  the  cursor  to  the  comer  to  disconnect  (the 
host's  cursor  was  never  affected,  but  his  movements  would  yank  the  observer's  cursor  back  to  the 
host's  cursor  location).  Version  3.0  addressed  that  by  proviing  the  observer  with  a  separate 
cursor  completely  under  their  control.  Version  2.01  dso  lacked  file  exchange  capabilities.  Due  to 
technical  difficulties  with  the  installation  of  the  updated  version  of  Timbuktu,  the  experimental 
sessions  were  all  run  with  the  2.01  version. 

Timbuktu/Remote.  This  software  package  allows  a  remote  Macintosh  to  connect  to 
another  Macintosh  system  via  modem  and  exchange  files,  communicate  via  typing  messages  in  a 
“Chat- Box”  which  appears  on  both  systems,  or  to  completely  control  the  “host”  Macintosh.  The 
operation  of  the  progr^  is  similar  to  Timbuktu.  When  used  in  conjunction  with  a  relay  Macintosh 
connected  to  a  network,  it  allows  the  remote  group  member  to  participate  as  if  he  were  directly 
connected  on  the  network. 

Computer-Supported  Distributed  Team  Work  Configurations 

The  hardware  and  software  acquired  for  this  project  allowed  us  to  examine  a  number  of 
computer-supported  distributed  team  work  configurations.  These  are  described  below. 

Distributed,  Interacting,  Screen  Sharing  Teams,  (Network  Timbuktu).  In 
this  configuration,  group  members  are  all  connected  via  a  networic  but  are  physically  separated 
from  one  another  (e.g.,  all  on  different  floors  of  an  office  building).  Phone  communications  are 
available  and  screen  and  computer  sharing  is  available  through  Timbuktu.  The  group  meeting  in 
this  case  occurs  in  real  time  via  conference  calling  and  immediate  sharing  of  visual  task  information 
via  Timbuktu.  This  type  of  configuration  is  one  Uiat  may  emerge  as  a  p^ominant  model  of  how 
groups  may  work  in  the  near  future  and  is  a  primary  focus  of  attention  for  us. 

Distributed,  Interacting,  Screen  Sharing  Teams,  with  Remote  (dial-in) 
Member  (Network  and  Remote  Timbuktu).  This  configuration  is  identical  to  the  above  but 
with  the  addition  of  a  relay  networked  Macintosh  that  is  equipped  with  Timbuktu/Remote.  This 
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permits  a  group  member  to  connect  to  the  netw(»1c  via  modem  and  participate  in  an  identical 
foshion  to  the  previous  scenario  by  controlling  the  relay  Macintosh  system. 

Distributed,  Interacting,  Screen  Sharing  Teams  with  Remote  (dial*in) 
Members  (Remote  Timbuktu).  In  this  configuration,  none  of  the  Macintosh  systems  are 
networked  together.  Instead  connections  are  established  via  Timbuktu/Remote  (xi  a  pairwise  basis. 

Distributed,  Networked,  IBM-Macintosh  Mixture.  This  configuration  mixes  both 
Macintoshs  and  IBM  systems  on  an  Apple  Talk  network  with  the  IBM  *^^ystems  equipped  with  '  i 
Apple  Talk  board  and  a  compatible  mail  system  (i.e.,  Microsoft  Mail),  this  case, 
ctxnmunications  with  the  IBM  systems  are  limited  to  E-mail  and  file  exchange. 

Distributed,  Networked,  IBM-Macintosh  Mixture,with  Remote  ?BM 
System.  This  configuration  is  identical  to  the  previous  one,  but  with  the  addition  of  a  remote 
IBM  system  that  connects  to  a  relay  IBM  system  on  the  Apple  Talk  netwOTk. 

College  of  Management  Behavioral  Research  Laboratory  Modifications 

To  empirically  examine  some  of  the  computer-supported  distributed  team  work 
configurations  described  above  requires  an  appropriate  lateratory  facility.  The  College  of 
Management  supports  a  Behavioral  Labtx'atcMy  which  consists  of  a  suite  of  4  small  rooms  (capable 
of  comfortable  seating  4-8  members),  1  large  room,  and  a  control  room  with  one-way  mirrors 
permitting  unobtrusive  observation  and  recording  (via  the  facility's  video  recording  equipment) 
into  all  other  rooms. 

Modific  dons  undertaken  in  the  behavioral  laboratory  to  facilitate  the  examination  of 
distributed  group  performance  include  the  following: 

1)  Installation  of  six  phone  lines  into  the  control  room  and  phone  jacks  in  all  experimental 
rooms.  Routing  of  the  six  phone  lines  into  the  experimental  rooms  is  flexibly 
accomplished  within  the  control  room,  thus  permitting  different  configurations  of 
computer-supported  distributed  team  work  performance. 

2)  Installation  of  two  additional  phone  jacks  in  each  of  the  experimental  rooms  for 
implementing  an  Apple  Talk  network.  This  particular  ctmfiguration  allows  us  to 
quickly  reco^igure  the  network  configuration  linking  the  various  experimental  rooms 
to  one  another. 

Figure  1  provides  a  schematic  diagram  of  the  t  lege  of  Management’s  Behavioral 

Research  Laboratory  .with  the  modificaticmsdescrit:  .oove.  As  can  be  seen,  the  Behavioral 
Research  Laboratory  now  provides  an  ideal  facility  for  systematically  setting  up  and  investigating 
issues  surrounding  computer-supported  distribu^  s  work. 


Insert  Figure  2  about  here. 


3.  Task  Development 


Task  Design  Considerations 

To  investigate  the  computer- supported  distributed  team  work  scenario  that  we  are  focusing 
on  (teleconferencing  with  screen  sharing),  required  the  development  of  a  computer-based  task 
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which  fulfilled  a  number  of  desirable  characteristics:  a)  relevance  to  United  States  Army 
Information  Systems  Command  (USAISC)  distrib  ted  team  work  situations,  b)  possession  of  a 
sufficient  degree  of  task  complexity,  c)  interdependencies  between  individual  group  member  tasks, 
d)  ability  to  build  in  potential  conflict  within  the  parameters  of  the  task,  e)  ability  to  implement 
screen  sharing.  The  budgeting  task  that  we  eventually  developed  incorporated  the  desired 
characteristics.  We  will  describe  how  in  the  paragraphs  and  sections  to  follow. 

USAISC  Relevant  Task  Scenario.  We  began  the  process  of  task  development  by 
discussing  possible  scenarios  for  computer-supported  distributed  team  work  that  the  U.S.  Army 
was  likely  to  face  with  Dr.  Jim  Gantt  of  AIRMICS.  Through  those  discussions,  we  selected  a 
budget  adjustment  scenario  where  regional  managers  are  faced  with  implementing  an  overall 
budget  cut  across  their  regions  and  the  projects  taking  place  in  each.  This  type  of  scenario  was  one 
that  currently  exists,  often  took  place  on  a  short  time  frame  (typically  precliidmg  face-to-face 
meetings),  and  involved  distributed  team  members  who  communicated  relevant  task  infcnmadon 
over  the  telephone.  In  such  situations,  failure  to  adequately  communicate  or  process  task  relevant 
information  during  group  interaction  can  result  in  errors  in  budget  reduction  decisions.  For 
example,  the  postponement  of  a  project  (e.g.,  radio  communications  device)  in  a  given  region  from 
the  current  budget  to  the  next  year's  budget  is  one  way  of  reducing  the  current  budget.  However, 
this  approach  does  yield  problems  when  the  postponed  project  was  supposed  to  prepuce  a  product 
to  be  used  in  a  project  in  a  different  region  that  was  not  postponed  (e.g.,  tank  production).  Ideally, 
such  errors  should  be  caught  by  the  group.  However,  time  pressure  and  the  relatively  narrow 
bandwidth  of  communication  permitted  by  telephone  interaction  may  be  contributing  factors  that 
can  hinder  the  identification  of  such  task  interdependencies  and  result  in  poorer  distributed  team 
budget  decisions. 

To  further  aid  the  development  of  our  task  and  our  understanding  of  the  budgeting  process, 
we  requested  meetings  with  USAISC  personnel  who  participated  in  such  budget  adjustment 
decisions.  Unfortunately,  we  were  unable  to  arrange  such  a  meeting  within  a  reasonable  amount 
of  time.  However,  we  did  meet  with  Barbara  Walsh,  a  budget  s^ialist  with  the  Georgia  Tech 
Research  Institute  (GTRI).  She  described  to  us  her  experiences  involved  in  dealing  with  similar 
types  of  budget  adjustment  decisions  and  the  overall  budgeting  process  fra  GTRI.  We  were  also 
able  to  meet  with  Ron  Creswell,  also  with  GTRI,  who  demonstrated  some  of  the  project  budget 
management  software  that  he  had  developed  in  Lotus  1,2, 3.  This  infonnation  was  used  to  ensure 
that  the  budget  adjustment  task  we  subsequently  developed  would  be  reasonably  analogous  to  such 
tasks  currently  existing  in  organizations. 

The  scenario  subsequently  adt^ted  for  the  task  was  a  budget  reduction  situation  involving 
three  regional  managers  of  a  fictitious  raganizatirai  who  are  infrai^  that  they  are  to  collectively 
cut  30%  out  of  their  overall  combined  budget  Decisions  as  to  how  and  where  budget  reductions 
are  to  be  taken  is  left  to  the  regional  managers,  who  each  manage  a  portfolio  of  five  projects 
totaling  $2.5  million. 

Each  of  the  fifteen  projects  were  assigned  rankings  (ranging  from  1-lS)  reflecting  its 
priority  (importance)  to  the  organization  as  a  whole.  In  Edition,  each  project  within  a  given  region 
was  also  assigned  regional  priraity  rankings  (1-5)  which  only  the  manager  of  that  region  was  privy 
to.  The  two  sets  of  rankings  permitted  us  to  set  up  situations  in  which  Ae  regional  priorities 
conflict  with  organizationtd  priorities.  This  conflict  becomes  important  when  the  group  as  a  whole 
has  to  identify  appre^riate  projects  to  cut  to  attain  the  30%  budget  cut  goal. 

Regional  managers  are  able  to  access  specific  budget  information  of  each  of  the  projects 
they  manage  including  detailed  breakdowns  of  expenditures  (via  appropriate  spreadsheets)  and 
specific  descriptive  information  (both  fra  public  as  well  as  private  consumption).  Modifications  to 
the  budgets  of  the  projects  assigned  to  them  was  accomplished  via  the  spr^shMts  which  handled 
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the  relevant  calculations  necessary.  The  sample  computer  task  session  will  be  illustrated  in  a  later 
section. 


Communications  between  the  Regional  Managers  are  possible  via  telephone  (each  manager 
had  a  phone  on  his  desk  with  preprograniWd  numbm  for  other  Regional  Managers)  and  screen 
sharing  via  their  computers  (networked  Mac  D's).  Instructions  concerning  how  to  use  the  phone 
to  contact  the  others,  how  to  set  up  a  conference  call,  and  how  to  use  Timbuktu  to  screen  share 
were  given  prior  to  task  performance. 

Task  Complexity.  As  noted  above,  each  regional  manager  controlled  the  budgets  of 
five  separate  proj^ts.  Each  of  these  project  budgets  contained  the  following  line  items:  personnel, 
equipment,  materials  &  supplies,  travel,  and  subcontractors.  The  total  expenditures  for  each  of 
these  respective  line  items  were  ^tailed  in  separate  spreadsheets.  The  project  description 
information  (both  public  and  private)  fra*  each  of  their  five  projects  was  available  for  review  by  the 
Regional  Manager  via  a  database-like  function.  In  some  instances,  this  information  indicated  the 
presences  of  interdependencies  among  the  five  projects  which  served  to  further  increase  the  level  of 
individual  task  complexity.  In  addition,  task  interdependencies  between  projects  across  group 
members  (described  below)  and  conflicting  organizational  (reflecting  the  importance  to  the 
CH-ganization)  and  personal  priorities  (reflecting  the  importance  for  the  individual  group  member  in 
his  region)  for  the  projects.contribut^  to  both  the  task  as  well  as  social  complexity  of  the  demands 
facing  the  individual  group  member. 

Interdependencies  Between  Individual  Group  Member  Tasks.  This  was 
accomplished  via  the  project  description  information  which  noted  the  projects  on  which  the  current 
project  depended.  For  example,  a  given  telecommunications  product  might  depend  on  the 
develt^ment  of  telephone  switching  components.  This  infenmation  was  used  to  establish 
interdependencies  between  the  projects  of  different  Regional  Managers.  Thus,  decisions  to  cut  or 
substantially  reduce  a  given  project  needed  to  be  based  not  only  on  the  merits  of  the  individual 
project,  but  on  the  merits  of  those  depending  on  it  as  well. 

Development  of  Conflict  Within  the  Parameters  of  the  Task.  The  overall 
budget  for  the  portfolio  of  five  projects  assigned  to  each  Regional  Manager  was  set  to  be  identical 
(i.e.,  $2,500,000)  so  as  to  foster  an  initial  sense  of  equality  among  the  Regional  Managers. 
However,  the  organizational  priorities  assigi^  to  each  of  the  projects  (Sec  Appendix  A)  were  set 
up  such  that  the  portfolio  of  projects  for  Region  3  consisted  almost  entirely  of  low  priority 
projects.  Thus,  ^e  bulk  of  any  organizational  level  budget  reduction  would  be  most  appropriately 
taken  out  of  Region  3.  Each  Regional  Manager  also  received  "classified"  information  concerning 
their  "regional"  priorities  (e.g.,  dicir  regional  boss'  preferences)  for  each  of  the  five  projects  they 
were  managing  (See  Appendix  A).  This  information  was  used  to  further  instill  potential  points  of 
dissent  between  Region^  Managers  about  cutting  certain  projects  through  the  use  of  conflicting 
organizational  and  regional  priorities.  For  example,  one  of  the  low  organizational  priority  projects 
held  by  the  Region  3  manager  was  also  his/her  highest  regional  priority. 

Ability  to  Implement  Screen  Sharing.  The  capability  to  screen  share  was 
accomplished  by  using  the  desk  accessory  based  program  "Timbuktu"  (described  earlier  in  the 
communications  software  section).  The  initial  design  of  our  task  included  a  "Communications 
Window"  interface  that  permitted  the  easy  use  of  screen  sharing  (via  Timbuktu)  by  the  Regional 
Manager. 

Task  Software  Development 

The  task  software, with  the  exception  of  the  screen  sharing  capabilities  (implemented  via 
Timbuktu),  was  developed  entirely  within  the  context  of  SupierCard.  The  initi^  portion  of  the  task 
software  consists  of  an  introductory  series  of  screens  which  collects  infmmation  about  the  subject 
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(name,  student  ID  number)  and  describes  the  task  scenario  and  regional  manager  role  that  the 
subject  will  be  playing.  This  segment  of  the  program  is  illustrated  in  Appendix  B. 

The  primary  portion  of  the  task  software  consists  of  the  various  windows  that  implement 
the  different  aspects  of  the  budget  adjustment  task.  These  windows  are  illustrated  in  Appendix  C 
along  with  the  scripts  for  the  buttons  and  fields  that  are  contained  within  them  as  well  as  a  general 
description  as  to  their  purpose.  Also  embedded  into  the  script  for  butttHis,  spreadsheet  fields,  and 
windows  were  some  segments  designed  to  "trap"  responses.  These  were  immediately  written  to 
another  file  as  they  occurred.  When  the  session  was  over,  summary  totals  were  also  calculated  and 
written  to  the  file.  Thus,  a  chronological  tracing  of  how  the  budget  task  was  completed  was 
available  for  every  participant. 

Sample  Task  Session 

The  actual  operation  of  the  program  is  best  described  by  reviewing  the  sample  task  session 
for  Region  2  illustrated  in  Appendix  D. 

Screen  1*  Upon  completion  of  the  initial  introduction  to  the  task  and  software  training 
session  (conducted  in  a  separate  room  on  a  different  computer-see  Methods  Section),  each 
Regional  Manager  was  faced  with  the  screen  shown. 

The  "Budget  Allocations"  window  appears  in  the  upper  left-hand  comer  of  the  screen. 

This  window  displays  the  original  and  revis^  budget  allocations  for  each  of  the  three  regions. 
Fields  which  are  patterned  (with  dots)  are  those  which  the  Regional  Manager  can  make  changes. 

In  this  case,  any  changes  in  the  revis^  budgets  for  Regions  1  and  3  are  to  be  entered  by  him.  That 
information  is  obtainable  by  either  calling  or  viewing  the  screen  of  the  managers  of  the  respective 
repons.  The  revised  budget  for  Region  2  cannot  be  directly  modified  in  the  budget  allocation 
window  since  it  is  dependent  on  changes  made  in  the  project  spreadsheets  and  is  automatically 
calculated.  Percentage  pie  charts  of  the  original  and  revised  budgets  for  tiie  three  regions  is  also 
viewable  by  "clicking"  on  the  appropriate  "Original"  or  "Revised"  column  heading.  This  window 
was  programmed  to  be  non-movable,  non-closable,  and  always  active  (floating  palette). 

The  "Communications"  window  appears  in  the  upper  right-hand  corner  of  the  screen.  This 
window  was  originally  constructed  to  permit  easy  access  to  limbuktu's  screen  sharing  functions. 
The  left  portion  controlled  which  Region  you  wished  to  observe.  The  middle  section  controlled 
visitor's  access  to  your  screen  (i.e.,  visitors  allowed,  or  not  allowed).  The  right-hand  section  of 
the  window  simply  contained  a  reminder  that  one  could  disconnect  from  viewing  another  Region's 
screen  by  "clicking"  on  the  scissors  icon  that  would  appear  in  the  upper  right-h:^  comer  of  ^eir 
screen.  However,  after  discussions  with  the  technical  support  people  at  Iwth  Silicon  Beach 
(SuperCard)  and  Farallon  (Timbuktu)  it  was  determined  tiiat  it  would  not  be  possible  to  simplify 
access  to  Timbuktu  in  this  fashion  (SuperCard  does  not  currently  permit  the  execution  of  desk 
accessories-a  limitation  currently  being  addressed  by  Silicon  Beach).  Instead,  Timbuktu  access 
was  implemented  by  constructing  a  custom  menubar  consisting  only  of  the  Apple  Menu  which 
contains  Timbuktu,  as  well  as  o^er,  desk  accessories.  This  window  was  programmed  to  be  non¬ 
movable,  non-closable,  and  always  active  (floating  palette). 


The  "Project  Directly"  window  displays  summary  budget  figure  for  each  of  the  projects 
as  well  as  information  concerning  the  project  name  and  manager.  Detailed  information  about  a 
particular  project  is  obtainable  by  clicking  on  the  appropriate  project  ID  number.  This  window  was 
programmed  to  be  non-movable  and  non-closable. 

Screen  2*  This  shot  illustrates  what  the  screen  looks  like  after  the  "Original"  and 
"Revised"  column  headings  in  the  "Budget  AUocations"  window  are  clicked  on.  Note  that  since 
there  have  been  no  changes  as  yet  in  the  budget  figures  that  the  pie  charts  are  identical.  When 
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budget  changes  are  made,  they  are  immediately  reflected  in  the  "Revised  Allocation"  flgure.  Both 
the  "Original  Allocations"  and  the  "Revised  Allocations"  windows  were  programmed  to  be  non¬ 
movable  and  always  active.  The  presence  of  the  close  box  (upper  left-hand  comer  of  each 
window)  indicates  that  users  can  close  these  windows  to  free  up  the  space  if  they  so  desire. 

Screen  3-  This  shot  illustrates  what  the  screen  looks  like  after  the  user  has  clicked  on 
"BIOOO"  in  the  "Project  Directory"  window.  The  "Project  Summary"  window  for  B 1000  puts  the 
Region  location,  Project  ID  #,  and  Project  Manago*  in  die  tide  bar  of  the  window  and  contains  two 
primary  segments.  The  left-hand  side  of  the  window  contains  a  summary  spreadsheet  of  the  line 
item  expenses  for  this  project.  The  lack  of  any  patterning  indicates  that  no  changes  can  be  made 
direcdy  to  the  cells  of  this  spreadsheet  Instead,  changes  are  made  by  "clicking"  on  a  given  line 
item  name  to  c^n  up  the  spreadsheet  for  that  item  detailing  the  expenditures.  This  will  be  more 
fully  illustrated  in  Screen  5. 

The  right-hand  portion  of  the  screen  displays  a  scrolling  field  that  contains  general 
information  about  the  project.  The  button  below  this  field  aUows  the  Regional  Manager  to  access 
"classified"  or  person^  information  about  the  project  which  are  intended  for  their  eyes  only.  This 
button  was  programmed  to  not  permit  access  to  the  "classified"  information  if  "ObsCTvers 
Allowed"  was  checked  in  the  "Communications"  window.  If  "Observers  Allowed"  was  instead 
checked,  clicking  on  the  button  would  bring  up  a  warning  message,  rather  than  the  classified 
information  field,  which  would  ask  the  manager  to  not  permit  any  observers  first  befcv^e  accessing 
this  field.  Upon  closing  the  "Project  Summary"  window,  the  classified  information  field  would 
again  be  hidden.  The  "Project  Summary"  window  is  programmed  to  be  closable,  but  non¬ 
movable. 

Screen  4-  This  screen  shot  illustrates  what  happens  when  the  Regional  Manager  clicks 
on  the  "Display  Classified  Information  for  Project"  button.  The  hidden  scrolling  field  cot.  raining 
the  classifit^  information  is  brought  to  the  front  and  completely  covers  the  general  information 
field.  Information  contained  in  this  field  are  the  Organizational  and  Regional  priorities  for  the 
project  as  well  as  other  relevant,  albeit  not  public,  information.  When  the  classified  field  is  visible, 
the  "Display  Classified  Information  for  Project"  is  superimposed  by  a  "Hide  Classified  Information 
for  Project"  button  which  allows  the  manager  to  do  just  that.  If  the  classified  information  field  is 
showing  when  the  user  clicks  on  the  "Observers  Allowed"  option  in  the  "Communications" 
window,  then  the  program  automatically  hides  the  classified  information. 

Screen  5*  This  screen  illustrates  what  happens  when  the  Regional  Manager  clicks  on  one 
of  the  line  item  names  (in  this  case  "Personnel")  in  the  summi^  spreadsheet  section  of  the  "Project 
Summary"  window  for  Project  BIOOO.  The  "Budget  Itemization"  window  displays  the  appropriate 
card  containing  the  detailed  spreadsheet  information  for  die  line  item  name  that  was  click^  on. 

This  window  was  programmed  to  be  non-movable,  closable,  and  always  active.  You'll  note  by 
the  patterning  in  tlw  cells  in  the  "Revised”  and  "%  C^t"  columns  that  the  Regional  Manager  can 
only  make  changes  there.  The  qrreadsheet  is  set  up  so  that  any  change  in  a  given  line  automatically 
calculates  the  appropriate  other  change.  For  example,  if  the  Regional  Manager  types  in  a  particular 
doUar  amount  for  the  revised  budget  for  a  given  line,  then  the  appropriate  percentage  cut  figure  is 
calculated  and  inserted  in  the  apprc^iriate  adjacent  space.  Simihuly,  if  the  manager  types  in  a 
{xuticular  %  cut  figure,  then  the  dcdlar  amount  of  that  cut  is  subtracted  from  die  initial  budget  and 
the  tqipropriate  revised  budget  number  is  insetted  into  the  ai^iropriate  adjacent  cell.  Warrungs  for 
invalid  entries  (i.e.,  revised  budget  amounts  greater  than  the  initial  amounts  budgeted,  and 
percentage  cuts  greater  than  lOf^)  are  given  with  the  affected  cells  then  being  restored  to  either  the 
initial  budget  amount  (for  cells  in  die  revised  column)  or  to  0%  (in  the  %  Cut  column).  In  all 
cases,  changes  made  in  these  line  item  spreadsheets  are  immediately  reflected  in  the  "totals"  line  of 
that  spreadsheet  (i.e.,  last  line),  the  budget  summary  spreadsheet  of  the  "Project  Summary” 
window,  the  appropriate  spot  in  the  "Budget  Allocations"  window  (i.e.,  for  Region  2),  and  in  the 
pie  chart  shown  in  the  "Revised  Allocations”  window.  In  the  latter  cases,  we  can  also  see  that  the 
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Region  2  Manager  has  gotten  in  contact  with  the  Region  1  and  Region  3  managers  and  obtained 
their  current  revised  budget  amount  for  their  respective  regions  (see  "Budget  Allocation"  window). 
We  can  also  see  that  the  66%  change  made  in  the  personnel  budget  of  project  B 1000  has  also  been 
reflected  in  the  "Budget  Allocations"  window.  All  of  these  changes  are  also  reflected  in  the 
"Revised  Allocation"  pie  chart  which  now  shows  the  relative  distribution  of  organizational  dollars 
across  the  regions. 

The  "Undo  All  Cuts"  button  allows  managers  to  completely  undo  all  changes  at  once  for 
the  given  spre^heet.  This  was  designed  to  facilitate  the  easy  correction  of  mistimes  and  to  permit 
private  "what-if '  budget  adjustments  that  could  quickly  be  removed  when  observers  were  present 
The  "Show  (Tut  Priorities"  button  brings  up  a  window  containing  the  organizational  priorities  for 
cutting  certain  items  within  a  given  budget  category  (e.g.,  persmnel). 

Screen  6-  This  screen  shot  illustrates  the  "Cut  Priorities"  window  for  personnel.  This 
was  designed  to  provide  a  guide  to  the  Regional  Managers  concerning  the  relative  general 
organizati<xial  inipcirtance  of  the  different  items  appearing  in  a  given  detailed  spreadsheet  This 
window  was  designed  to  be  non-movable,  closable,  and  always  active. 

Budget  Task  Revisions 

The  sample  task  session  reviewed  in  the  previous  section  illustrates  the  version  of  the 
budgeting  task  software  that  was  used  for  the  final  experimei  tal  session  (4).  That  version 
incotix>rated  some  revisions  that  were  implemented  after  the  lirst  day's  experimental  sessions  in 
response  to  participants'  debriefing  comments  as  well  as  our  own  personal  observations  (for 
further  details  see  "Findings:  Group  Process"  in  the  "Experimentation"  section).  The  software  and 
experimental  procedure  revisions  were: 

1 )  Centralizing  of  all  classified  information  for  a  given  project  in  one  field  so  that  it  could 
be  accessed  quickly  by  one  button  push  at  the  level  of  the  "Project  Summary"  window 
(see  Screen  4  of  Appendix  D).  Previously,  classified  information  fora  given  budget 
line  item  was  accessible  only  from  the  appropriate  card  in  the  "Budget  Summary" 
window.  Participants  complained  that  a  great  deal  of  work  had  to  be  done  to  fiiUy 
examine  all  of  the  classified  information  fix’  a  given  proj^t  Moreover,  not  all  of  the 
budget  line  items  had  classified  information  associate  with  it;  a  fact  which  participants 
could  only  discover  by  going  through  all  the  procedures  to  open  that  classified 
information  field.  Centralizing  the  classified  inftnmation  succeeded  in  addressing  that 
problem. 

2)  Putting  both  the  organizational  and  regional  priority  information  about  a  given  project  in 
a  prominent  location  in  the  classified  information  field  (see  Screen  4  of  Appendix  D). 
This  was  done  to  highlight  the  potential  conflict  that  might  exist  for  a  given  regitxial 
manager  between  the  projects  that  while  low  on  the  organizational  priority  u>tem  pole, 
was  highly  valued  in  their  region. 

3)  Distributing  to  participants  a  summary  sheet  detailing  the  organizational  pricxity 
rankings  of  all  15  projects  across  all  of  the  three  regions  (see  Appendix  A).  Pnor  to 
this  change,  the  organizational  priority  information  about  a  givoi  project  was  contained 
in  one  of  its  budget  item  classified  information  fields.  Thus,  each  regional  manager 
knew  the  organizational  priorities  for  his  projects,  but  not  for  die  otiier  10.  We 
assumed  that  information  would  be  communicated  as  pan  of  the  group  problem  solving 
and  decision  making  process.  This  was  apparantly  too  subtle  and  did  not  take  into 
account  that  some  of  the  regional  tnanagera  might  prefer  that  the  others  did  not 
immediately  know  what  the  organizational  priorities  for  their  portfolio  of  projects  were. 
To  aid  managers'  ability  to  identify  those  projects  which  were  prime  candidates  for 
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budget  cutting,  we  decided  to  distribute  that  information  at  the  beginning  of  the  actual 
task  session. 

4)  Altering  the  required  amount  to  be  cut  from  30%  to  20%,  but  with  the  added  restriction 
Aat  only  low  organizational  priority  projects  (8-15)  could  be  cut  This  change  was 
implemented  during  sessicm  4  and  was  designed  to  further  create  an  imbalance  between 
regions  with  regards  to  the  budget  reductions  they  could  put  in  place  in  their  own 
region  and  to  increase  awareness  that  further  cuts  would  have  to  come  from  certain 
regions.  The  changes  resulted  in  Region  2  having  only  one  project  that  could  be  cut 
Re^on  1  having  two,  and  Region  3  laving  four  out  of  five  Aat  were  cuttable.  We 
anticipated  that  these  changes  would  result  in  individual  managers  ascertaining  more 
quickly  that  they  needed  to  contact  the  other  regions  to  be  able  to  accomplish  their 
^up  task. 

4.  Demonstrations  of  Feasibility  of  Distributed 
Team  Work  Configurations 

Distributed,  Interacting,  Screen  Sharing  Teams,  (Network  Timbuktu) 

The  first  set  of  trials  with  Timbuktu  were  ccHiducted  in  the  Classroom- 2000  facility. 

College  of  Management,  Georgia  Tech.  In  this  facility  there  are  35  MACIIs  networked  for 
instructional  purposes.  The  underlying  Local  Area  Network  used  is  Ethernet.  All  the  MACIIs 
have  Ethertalk  cards  installed.  The  data  transfer  rate  in  this  network  is  10  Mbits/second.  This  trial 
run,  conducted  with  4  MACIIs,  was  useful  for  familiarizing  the  researchers  aware  of  the 
limitations  of  Timbuktu. 

The  following  items  regarding  Timbuktu  were  observed: 

•  The  color  information  on  the  observed  MACIIs  screen  was  not  transferred  to  the 
observing  MACIIs.  Hence  this  precluded  the  use  of  color  in  the  development  of  the  task 
software. 

•  One  user  could  observe  any  other  single  MACII. 

•  Several  users  could  be  observing  the  same  MACTI. 

•  There  could  not  be  any  daisy  chaining  of  MACIIs,  i.e.,  a  user  A  could  not  observe  another 
user  B  who,  in  turn,  was  observing  a  third  user  C. 

•  The  need  for  a  means  of  communication  between  users  was  felt.  The  (Tlassroom  2(X)0 
facility  has  no  phones.  The  reriKne  version  of  Timbuktu  has  a  message  note  pad  which  the 
users  at  the  two  sites  can  use  to  exchange  messages  in  case  they  do  not  have  a  phone 
connection  available.  The  networic  Timbuktu  tested  in  Qassroom  2000  does  not  possess 
this  feature. 

Distributed,  Interacting,  Screen  Sharing  Teams,  with  Remote  (dial-in)  Member 
(Network  and  Remote  Timbuktu) 

This  demo  involved  three  MacIIs  (see  Figure  2).  A  remote  MACmCX  (Computer  A)  was 
used  to  dial  in  to  a  MACIICX  (Computer  B)  using  a  9600  bps  Hayes  V-Series  modem.  The 
dialing  in  was  done  via  Remotc-Timbuktu.  The  second  MACIICX  ((Computer  B)  was  one  of  a 
number  of  computers  which  were  connected  to  the  College  of  Management's  AppleTalk  local  area 
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network.  Computer  A  had  control  over  Computer  B.  Computer  B  was  programmed  to  answer  the 
phone  in  1  ring.  The  following  were  observ^: 

•  File  transfer  using  Timbuktu  between  the  two  computers  was  tested  and  proved  to  be 
successful. 

•  The  message  note  pad  available  in  Remote  Timbuktu  proved  to  be  a  useful  feature. 

•  The  use  of  Multifinder  in  the  Macintosh  operating  system  of  Ctxnputer  B  caused  the  system 
to  crash.  In  order  to  conduct  furtha-  tests.  Multifinder  was  disabl^  in  all  the  MAQIs. 

•  A  few  other  system  features  not  germane  to  the  task  were  disabled  from  the  computers;  a 
Type  Manager  program  and  a  clock  desk  accessory. 


Insert  Figure  3  about  here. 


The  AppleTalk  networic  operates  at  375  Kbits/second  (much  slower  than  the  Qassroom 
2(XX)  demonstration  just  described).  Then  a  regular  Timbuktu  connection  was  established  between 
Computer  B  and  another  MACIl  on  the  AppleTalk  network.  When  this  second  connection  was 
established,  Computer  A  could  control  Computer  C.  The  project  (budget)  software,  written  in 
SuperCard,  was  then  run  on  Computer  C.  The  major  point  that  emerged  was: 

•  Since  this  experiment  was  conducted  on  a  regular  wnidng  day,  the  AppleTalk  networic 
was  busy  and  the  response  time  to  see  the  effects  of  issuing  a  command  to  the  budget  program  was 
very  slow.  Whether  tf»e  delay  is  due  to  the  9600  bps  phone  link  or  to  the  traffic  on  tire  AppleTalk 
network  was  not  established. 

Distributed,  Interacting,  Screen  Sharing  Teams  with  Remote  (dial>in)  Members 
(Remote  Timbuktu) 

The  communications  software,  Timbuktu,  comes  in  a  remote  version  allowing  computers 
to  send  files,  pass  messages  in  a  "chat  box"  and  have  remote  control  through  the  telephone  system. 
We  had  purchased  9600  bps  modems  in  order  to  determine  whether  the  operaticmal  aspects  of 
remote  Timbuktu  made  computer-supported  distributed  group  work  feasible  tiirough  the  telephone 
network. 

In  a  sequence  of  trials,  we  communicated  at  1200, 2400,  and  9600  bps.  The  Timbuktu 
Remote  manuid  recommends  9600  bps.  Our  experience  would  bear  this  out  At  1200  bps,  all 
functions  were  extremely  slow.  At  2400  bps,  the  functions  were  improved,  but  protrably  would 
be  rarely  used  except  by  people  with  a  great  deal  (tf  patience.  At  96()0  bps,  the  functions  were 
acceptable,  though  still  somewhat  slow  relative  to  the  performance  of  the  network  version 
described  above.  We  would  expect  that  most  users  would  have  access  to  2400  bps  nxxlems 
(because  of  their  relatively  nxxlest  cost).  The  widespread  use  of  packages  such  as  Timbuktu- 
Remote  will  probably  depend  on  lower  prices  fw  9600  bps  (and  possibly  faster)  modems. 

Distributed,  Networked,  IBM>Macintosh  Mixture,with  Remote  IBM  System 

Attempts  to  connect  the  IBM  machine  to  the  Apple  LocalTalk  netwcxk  through  a  modem  to 
achieve  "seamless"  interface  have  been  only  partially  successful. 

At  the  College  of  Management  (COM)  facility,  an  IBM  PS/2-  model  70,  with  a  DayStar 
Digital  AppleTalk  board  for  Micro  Qiannel,  was  connected  to  the  Apple  LocalTalk  network.  This 
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netwtH’k  hosts  all  the  Faculty/Staff  Macintosh  computers,  AppleShare  haid  disks  and  a  variety  of 
laser  printers.  It  is  also  connected  to  Georgia  Tech's  GTNet  by  Fastpath  InterBridge,  which  in 
turn  is  conn^^'ted  to  a  dozen  other  LocalTidk  zones.  With  Microsoft  Mail  2.0  running  both  on  this 
PS/2  node  and  a  Macintosh  server,  we  could  send  and  receive  mail,  graphics  and  files.  This  PS/2 
workstation  also  has  an  Everex  2400  bps  modem  so  that  it  could  be  accessed  by  a  remote  IBM  rc 
or  PS/2  through  telephone. 

At  the  Spebnan  subcontractor's  site,  all  machines  on  the  PC  LAN  and  Token  Ring 
networks  share  a  single  server.  The  subcontractor  is  using  PC-Chalkboard  Plus  to  conmiunicate 
with  students  over  the  netwtxk.  PC-Chalkboard  Plus  allows  the  Teacher"  to  broadcast  the 
teacher's  screen  to  all  the  students'  screens.  The  Teacher"  can  also  "Peck"  at  a  student's  screen 
and  control  the  student's  machine  remotely.  If  desired  the  'Teacher"  can  broadcast  a  student's 
screen  to  all  the  other  students.  There  are  pieces  software  which  have  been  reviewed,  Close-Up 
Lan,  Qose-Up  Suppori/ACS  aixl  Close-Up  Customer/Terminal  which  allow  for  communication 
between  computers  on  IBM  compatible  networks  connected  duough  modems  to  communicate  in  a 
manner  like  tlie  computers  using  PC-Chalkboard  Plus  on  the  bridged  PC  LAN  and  Token  Ring 
networks. 

The  subcontractor  is  also  currendy  involved  in  a  separate  pro^  connecting  AT&T 
machines  on  an  Ethernet  by  means  of  a  Broadband  LAN  to  the  machines  already  connected 
together  through  the  bridg^  networks.  This  gateway  is  being  created  with  an  Allen-Bradley 
Network  Interface  Module  in  the  server  for  the  already  Inid^  networks.  Novell  software  is 
being  used  to  have  machines  on  the  three  networks  communicate  with  each  other.  The  Unix 
mactdnes  on  the  Ethernet  will  run  Novell  software  within  a  DOS  shell  to  connect  to  the  server 
connecting  the  two  bridged  networks. 

From  our  current  experience  with  commercially  available  prcxlucts,  we  found  that  we  will 
be  able  to 

i)  communicate  by  a  "chat  box"  and  send/receive  files  between  two  IBM  PS/2  workstations  using 
the  telephone; 

ii)  communicate  and  send/receive  files  between  an  IBM  PS/2  and  a  Macintosh  computer  in  a 
LocalTalk  network  using  Microsoft  Mail  2.0. 

The  above  two  capabilities  together  imply  that  it  is  possible  for  a  member  of  the  group  at  a 
remote  site  using  an  IBM  PS/2  or  PC,  to  take  part  in  a  budgeting  session.  However,  the  budgeting 
software  written  using  SuperCard  for  Macintosh  con^uters  will  noi  be  readily  available  tt>  the 
remote  member.  We  contrast  this  situation  to  the  case  when  the  remote  member  also  was  using  a 
Macintosh. 

Currently,  the  modem  software  and  the  AppleTalk  MC  board's  software  running  on  the 
relay  PS/2  workstation  do  not  interface  with  each  ^er.  Hence,  one  human  being  is  n^ied  to 
relay  the  information.  However,  it  is  possible  to  write  some  batch  files,  (say  modem.bat)  to 
initiate  the  remote  session,  which  upon  termination  automatically  executes  the  instructions  relayed 
through  modem  during  the  session.  Though  it  is  ctmceptually  feasible,  it  needs  to  be  tested.  We 
also  learned,  through  a  vendor,  that  if  we  use  the  TOPS  network  for  connecting  the  Macintosh 
computers  then  the  Shiva  Net  Modem  will  let  a  remote  IBM  PS/2  directly  access  the  networic. 
These  two  ideas  need  to  be  explored  in  future. 

V.  Experimentation 


Description  of  Research  Setting 
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A  key  goal  of  this  research  project  was  to  develt^  a  labwatory  setting  where  research  on 
computer  supported  team  work  could  take  place.  To  this  end,  the  facilities  described  in  Section  2 
were  naodifled,  a  computer  network  installed,  phone  lines  installed,  and  so  forth.  The  task 
described  in  Section  3  was  develc^red  to  both  demonstrate  the  feasibility  of  team  problem  solving 
through  computer-supported  facilitates  and  to  actually  observe  groups  trying  to  solve  the  problem. 
Therefore,  4  experimental  groups  were  recruited  to  participate  in  the  study. 

Method 

Participants 

All  participants  were  Ph.D.  students  from  Georgia  Institute  of  Technology.  Four  students 
were  from  the  College  of  Management  and  eight  students  were  from  the  School  of  Psychology. 

We  recruited  these  students  because  we  want^  individuals  who  would  cooperate  with  our 
extensive  debriefing  needs  and  also  would  participate  in  a  situation  where  the  software/hardware 
configuration  was  still  somewhat  untested.  We  had  found  through  initial  tests  of  the  equipment 
that  system  crashes  and  logical  errors  were  possible.  We  wanted  our  participants  to  be  tolerant  of 
these  flaws  and  to  allow  us  to  "reboot"  the  system  and  continue  their  work. 

Each  experimental  session  began  with  3  participants  showing  up  at  the  ^pointed  time  and 
room.  They  all  understood  that  the  session  would  take  about  2  hours.  The  participants  sat  in  the 
large  experimental  room  while  one  of  the  researchers  explained  die  basic  nature  of  what  was  going 
to  take  place.  They  were  instructed  as  to  the  sequence  of  events,  their  role  as  "pilot"  subjects,  the 
operation  of  the  software,  and  the  debriefing  to  follow. 

After  initial  instruction,  questions  were  answered.  Next,  each  of  the  participants  was  lead  to 
an  experimental  room  where  the  computer  was  set  to  give  further  explanation  of  the  role  the 
individual  was  to  play  in  the  study  (See  Appendix  B).  A  fictitious  company  was  described  which 
had  a  Research  &  Development  budget  that  was  allocated  over  15  projwts.  Each  of  the  3 
participants  represented  a  regional  manager  and  was  in  charge  of  S  project  budgets.  The  projects 
were  listed  by  name  and  organizational  priority  (See  Append^  A).  Further  information  about  each 
project  was  to  be  found  in  Ae  budgeting  software  that  would  be  learned  and  used  during  the  course 
of  Ae  study. 

When  each  participant  had  Bnished  reading  the  introductory  notes,  they  were  asked  to  call 
"Training  Headquarters"  which  was  the  control  room  for  the  Management  Research  Lab.  When  all 
calls  had  been  received,  the  researchers  called  all  of  them  back  and  asked  them  to  come  down  to 
training  hea^uarters  where  the  training  demonstration  would  take  place. 

The  training  demonstration  consisted  of  a  computer  that  had  the  budgeting  software  installed 
with  some  regions  and  projects  different  from  drose  that  die  subjects  would  be  working  with.  One 
of  the  researchers  then  demonstrated  the  various  functions  of  the  budgeting  software. 
Demonstrations  included  opening  the  graphics  windows,  the  project  budget  windows,  the  budget 
line  windows  and  so  forth.  Changes  in  budget  lines  were  demonstrated.  For  diose  participants 
who  had  not  used  a  Macintosh  Omputer  before,  they  were  given  the  chance  to  use  the  "mouse"  to 
move  the  cursor  and  change  entries  in  the  budget  line  windows. 

Instructions  were  also  given  on  using  the  Timbuktu  "screen-sharing"  capability.  Because  of 
some  software  incompatibilities  it  was  inqiossible  to  have  a  single  button  push  to  connect  to  other 
regions.  Rather,  the  participants  had  to  invdte  Timbuktu  via  die  desk  accessory  menu  bar. 

In  addition  to  the  budgeting  software  and  Umbuktu  demonstration,  the  "training  session" 
also  included  instructions  on  using  the  conference  calling  features  of  the  phone  system  as  well  as 
further  details  about  the  scenario  diey  were  taking  part  in. 
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After  the  training  sessicm,  the  participants  were  led  back  to  their  respective  rooms  and  told 
that  they  would  have  about  45  minutes  to  complete  their  targeted  cuts. 

At  this  point  in  time,  all  participants  were  left  on  their  own.  If  they  called  training 
headquarters  with  questions,  they  were  answered.  If  they  had  a  software  crash,  the  researchers 
could  see  this  from  the  control  room  and  would  walk  over  to  the  tqrpropriate  romn  and  "reboot"  the 
system.  The  budgeting  data  base  was  up^ted  in  real  time  so  that  even  when  the  system  crashed 
the  budget  revisions  were  saved  and  retrieved  on  reboot 

As  the  sessioi  reached  the  30-40  minute  mark  in  elapsed  time,  all  of  the  participants  were 
notified  of  the  time  remaining.  Because  of  the  explmatory  nature  of  these  sessions,  we  didn't 
restrict  the  sessions  to  45  minutes.  If  progress  was  being  made  and  the  groups  appeared  to  be 
moving  into  a  stage  of  discussion  whereby  the  Timbuktu  software  might  be  accessed,  the  groups 
were  allowed  to  continue. 

Observation  and  Measurement. 

Researchers  remained  in  the  research  lab  control  room  during  the  sessions.  All  participants 
were  visible  through  one-way  mirrors.  In  addition,  experimental  room  intercoms  were  turn^  on 
so  that  conversations  could  he  heard.  On  the  second  day's  sessions,  the  participant  playing  the 
role  of  the  Region  3  manager  was  video-taped. 

Debriefing.  After  the  session  was  complete,  the  participants  were  brought  back  to  the 
large  lab  room  and  debriefed.  This  debriefing  consisted  of  a  series  of  questions  concerning: 

1 )  member  strategies  concerning  the  task 

2)  use  of  the  Timbuktu  screen  sharing  software 

3)  coordination  of  efforts 

4)  perceived  difficulty  of  the  task 

5)  interest  in  the  task 

6)  perceived  conflict  inherent  in  the  task 

7)  anything  else  that  they  thought  relevant 

Each  participant's  final  revisions  was  obtained  by  saving  their  final  version  oi  the  budgeting 
software  data  base  and  recording  the  final  numbers.  Each  participant’s  software  use  history  was 
obtained  by  "tnq)ping"  all  button  pushes  and  field  accesses.  This  history  was  then  summarized  by 
totalling  tlw  number  of  accesses  to  each  project  and  the  line  items  within  budget. 

Given  dte  exploratory  nature  ot  this  research,  we  attenqxed  to  gather  a  wide  range  of  data  and 
information  about  how  the  sessions  went  We  did  not  measure  and  obsove  in  the  hopes  of  testing 
hypotheses  but  rather  to  get  a  better  feeling  about  how  the  experimental  sessions  wait  and  how 
individuals  within  these  session  could  suggest  modifications  to  both  the  scenario,  the  training,  and 
the  software. 

Findings 

Group  Process 

The  first  set  of  findings  concerns  the  group  process  observed  during  the  sessions.  During 
sessions  1  &  2,  it  was  notable  that  no  attempt  was  made  to  communicate  to  each  other  (through 
phone  or  computer)  until  about  30  minutes  of  individual  work  cm  the  project  budgets.  Upon 
debriefing  the  participants  about  this  afterwards,  we  were  told  that  it  took  about  that  long  to  leam 
about  the  projects.  In  part,  this  was  because  much  of  the  information  about  a  project  was 


Distributed  Gxnputer  Supported  Team  Work 

Page  23 


accessible  only  through  pushing  the  classified  information  button  for  each  budget  line  item.  In 
addition,  the  participants  told  us  that  they  all  assumed  that  they  were  each  supposed  to  cut  30% 
from  their  projects.  Although  we  had  given  Region  3  far  more  low  priority  projects,  the 
participants  told  us  that  the  equitable  approach  was  to  all  cut  30%. 

Because  the  intent  of  the  task  was  to  make  it  a  "group"  task  with  some  inter-member  conflict, 
we  changed  both  the  software  and  the  scenario  for  the  second  day  (sessions  3  &  4).  The  changes 
involved  moving  all  classified  infcxmation  from  the  budget  line  level  to  the  project  level.  This 
resulted  in  the  participant  being  able  to  read  all  classified  information  about  a  project  at  one  dme. 
More  detail  on  these  changes  can  be  found  in  the  section  of  this  report  titled  "Budget  Task 
Revisions".  The  second  change  involved  giving  each  participant  a  list  of  all  IS  projects  (across  the 
three  regions)  and  their  organizational  pri(»ities.  It  was  thought  that  this  would  make  the 
difference  in  priorities  between  regions  much  more  salient  and  therefore  the  group  members  would 
want  to  establish  something  other  than  equal  shares  of  the  budget  cuts. 

Session  3  during  the  second  day  progressed  much  the  same  as  the  sessions  during  the  first 
day.  There  was  one  early  phone  call  between  regions  2  &  3  almost  immediately  after  the 
participants  returned  to  their  offices  from  the  training  headquarters,  but  this  was  very  brief.  The 
panicipants  were  only  deciding  to  work  on  their  projects  individually  first  and  later  to  talk  about  the 
overall  task.  The  first  conference  call  occurred  about  30  minutes  later. 

For  the  final  session  (#4)  we  altered  the  scenario  (once  again)  to  try  to  invdce  more 
information  sharing  earlier  in  the  session.  We  stated  that  only  projects  with  organizational 
priorities  8  to  IS  could  be  cut  and  that  the  overall  cut  would  have  to  be  20%.  Tliis  change  created 
the  situation  that  the  Region  2  manager  had  only  one  project  that  could  be  cut  and  the  Region  1 
manager  had  2  projects  that  could  be  cut.  On  the  oth^  hand,  the  Region  3  manager  had  4  (of  S) 
projects  that  could  be  cut. 

Interestingly,  this  scenario  created  the  situation  whereby  the  Region  2  manager  very  quickly 
cut  what  she  though  was  appropriate  from  her  one  low  priority  project  Then  she  looked  fOT 
another  role  to  play  in  the  group  (learned  from  debriefing).  She  telephoned  Region  3  to  ask  what 
she  could  do  to  help.  This  then  M  to  the  use  of  Timbuktu  to  observe  what  Region  3  had  on  his 
screen.  Some  of  this  observation  was  done  while  talking  on  the  phone.  Other  parts  of  it  was  done 
passively  (e.g.  without  phone  contact). 

The  group  soon  engaged  in  conference  calling  and  began  to  share  information  about  cuts. 

The  Region  1  manager  had  decided  to  cut  from  some  of  the  untouchable  projects  (priorities  1  to  7). 
The  Region  2  manager  told  him  this  was  not  permitted  and  the  budgets  were  restored. 

Group  Performance 

Performance  was  assessed  by  how  close  the  groups  came  to  meeting  the  required  percentage 
of  cuts.  These  results  appear  in  Table  1.  As  can  lx  seen,  in  Session  3,  tlx  Group  achieved  cuts  of 
26.9%  (out  of  a  goal  of  30%).  Interestingly,  the  group  in  Session  4  achieved  an  overall  cut  of 
7.8%  (out  of  a  goal  of  20%).  This  group  was  wc^ng  under  the  restriction  that  they  could  only 
cut  firem  projects  with  priorities  8  -  IS.  As  noted  above,  this  restriction  meant  that  tte  person  in 
Region  2  only  had  one  project  to  woric  on  and  this  project  was  cut  by  29.1%. 


Insert  Table  1  about  here. 


Another  way  to  look  at  the  budget  cutting  is  to  see  what  accounts  for  the  differences  in 
percentage  cuts  taken  in  the  project  budgets,  '^is  can  be  done  by  using  a  multiple  regression 
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procedure  whereby  the  %  cut  is  the  dependent  variable  and  the  independent  variables  are  starting 
budget  and  the  various  cues  that  we  built  in  concerning  what  the  pricxities  were  as  well  as 
interdependencies  between  projects. 

These  regressions  are  very  tentative  given  the  small  number  of  observations.  We  look  at 
them  only  for  purposes  of  further  describing  the  data  obtained  and  not  for  purposes  of  making 
inferences  to  populations.  We  used  multiple  regressions  on  the  first  3  sessions  combined  as  well 
as  each  of  the  4  sessions  individually.  The  results  appear  in  Table  2.  The  multiple  is 
frequently  interpreted  as  the  degree  of  model  fit  For  the  first  3  sessions  combined  the  was  .14 
which  suggests  that  the  group  members  were  not  making  their  cuts  acco^ng  to  the  "cues”  we  built 
in.  However,  when  we  broke  the  groups  out  separately,  the  first  group  had  an  r2  of  .47  which 
suggests  a  pretty  good  fit.  The  second  group  h^  an  R^  of  .05  which  is  a  very  poor  fit.  Finally, 
the  the  third  and  fourth  groups  had  an  r2  of  .60  and  .80.  These  latter  two  numbers  are  comfoning 
because  they  suggest  that  our  changes  in  procedure  between  the  first  and  second  days  improved  the 
salience  of  ^e  cues. 


Insert  Tables  2  and  3  about  here. 


The  poor  fit  for  the  second  group  can  be  better  understood  by  looking  at  Table  3  which 
displays  the  number  of  times  each  individual  accessed  a  project  and  a  line  item  within  a  project. 
Al^ough,  some  data  were  lost  because  of  system  crashes,  it  is  clear  that  the  participants  in  Session 
2  showed  less  activity  than  the  participants  in  the  other  sessions.  Reports  from  the  Session  2 
participants  suggests  that  the  budget-cutting  task  was  novel  to  them  and  using  the  Macintosh 
computer  was  a  new  experience.  This  probably  caused  them  to  spend  more  time  becoming  familiar 
with  the  software  and  perhaps  indiscriminantly  cutting  as  oppos^  to  sharing  information  about 
project  priorities. 

Software  and  Use 

Through  observation  and  debriefing,  it  was  obvious  that  the  participants  took  quite  a  bit  of 
time  to  beccane  familiar  with  the  operation  of  the  software,  especially  those  who  had  neither 
budgeting  experience  nor  Macintosh  experiertce.  One  participant  spent  much  of  the  time  learning 
how  to  operate  the  software. 

The  Timbuktu  software,  likewise,  created  some  unpediroent  in  its  operation.  The  operation 
of  the  menu  bar  option  along  with  the  options  concerning  "observe",  "control",  "no  observers" 
mode  did  probably  prevent  experimentation  with  it  by  some  groups.  Upon  debriefing,  groups 
usually  said  that  they  didn't  feel  the  need  to  share  screens.  That  is,  so  much  of  their  time  was  taken 
up  learning  about  the  projects  and  cutting  the  30%  which  became  the  expected  amount,  that  they 
never  reached  the  stage  where  the  task  was  group  work  that  might  have  benefited  from  the  screen 
sharing  capacity.  The  conference  phone  calling  provided  a  satisfactory  means  of  exchanging 
information. 

It  became  clear  that  both  the  budgeting  software  and  die  Timbuktu  software  operation  would 
benefit  from  further  training.  Some  of  the  participants  suggested  that  we  have  a  session  devoted 
strictly  to  software  training. 

There  was  one  comment  about  the  response  time  of  the  software.  The  Timbuktu  softw^, 
when  in  use,  does  tend  to  slow  down  the  ope^on  of  the  computer  being  observed.  In  addition, 
the  SuperCard  software,  in  which  the  budgeting  software  was  written,  is  not  oriented  towards 
numerical  calculations,  thus  slowing  down  when  gmng  through  the  updating  process  (to  related 
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spreadsheets)  following  the  change  in  a  budget  line  number.  The  response  times  will  appear 
somewhat  slow  relative  to  a  standard  spreadsheet.  Since  only  one  participant  mentioned  the 
response  time,  we  don’t  expect  this  to  be  a  majw  problem  in  either  further  studies  in  our  lab  or  in 
network  use  of  Timbuktu.  As  noted  in  an  earlier  section,  the  Remote  Timbuktu,  will  seem  quite 
slow  con^ared  to  the  network  version.  This  problem  is  exacerbated  when  the  Remote  Computer 
is  linked  to  a  network  through  a  relay  computer. 

6.  Recommendations 

Technical  Considerations  for  Computer  Supported  Distributed  Team  Work 

From  our  experience  we  found  that  a  designer  of  a  Distributed  Group  Decisitm  Support 
System  (DGDSS)  must  pay  attention  to  several  issues.  We  enq>hasize  the  fact  that  the  setting 
envisioned  in  our  research  calls  for  interfacing  different  systems  which  gives  rise  to  additional 
considerations  in  software  design.  The  main  points  to  be  considered  are: 

1 )  Transmission  Speed:  For  the  purposes  of  sharing  of  screens,  we  used  the  Timbuktu 
software.  If  modems  and  the  "renx>te"  version  of  the  software  are  to  be  used,  we  recommend 
tiiat  at  least  9600  bps  modems  be  used.  Though  we  did  use  slower  modems,  the  response 
times  are  not  tolerable.  We  do  note  that  even  9600  bps  modems  are  not  satisfactory  for 
sending  bit  mapped  graphics. 

LocalTalk  /  PhoneNet  local  area  networks  give  reastmable  response  times;  however,  the  load 
on  the  network  imposed  by  other  users  must  be  taken  into  account  The  current  version  of 
Timbuktu  does  not  support  color.  If  it  were  to  support  color  we  expect  that  a  sp^up  factor 
of  8  at  least  in  transmission  speed  will  be  called  for  since  the  Macintosh  uses  8  bits  to  store 
coIot.  This  is  under  the  assumption  that  the  hypothetical  new  version  maintains  a  copy  of  the 
color  lookup  table  at  the  guest  conqiuter  also. 

2)  Color:  The  budgeting  and  other  software  should  be  designed  in  black  and  white  mode;  else, 
it  should  be  designed  so  that  the  user  could  turn  it  to  black  and  white  mode  when  necessary. 
This  restriction  is  imposed  by  the  Timbuktu  software  used  for  screen  sharing/control  of 
another  Macintosh.  Timbuktu  transmits  cmly  the  black  and  white  version  of  the  screen.  When 
the  monitor  is  set  to  display  color,  the  substitution  of  black  and  white  for  various  colors  could 
render  the  transmitted  cqiy  difficult,  even  impossible,  to  interpret. 

3 )  Screen  Size :  While  designing  the  budgeting  and  other  software,  one  should  remember 
that  tiie  guest  (observer)  may  not  have  a  large  Mac  n  type  screen.  This  implies  that  every 
member  of  the  group  should  have  the  same  screen  size  or  the  st^tware  must  be  designed  for 
the  smallest  (Macintosh  Plus)  screen  size.  The  forst  conditicm  is  hard  to  achieve  in  a  diverse 
organization.  The  second  condition  may  not  be  a  good  solution  either,  since  the  budgeting 
software  is  expected  to  be  used  most  of  the  time  by  a  single  user,  and  it  may  be  inefficient  not 
to  folly  utilize  tiie  larger  screen.  A  possible  sdution  couM  be  to  use  a  commercially  available 
control  panel  software  called  "Stepping  Out  II",  which  permits  a  Macintosh  with  a  small 
screen  to  view  various  portions  of  Ae  larger  screen  (a  facsimile  of  the  larger  screen  is 
maintained  in  memory).  If  one  were  to  use  tiiis  strategy,  attention  must  paid  to  die  memory 
availability.  A  better  solution  may  lie  in  designing  the  budgeting  software  so  that  die  host  can 
move  and/or  resize  the  windows  of  the  software,  befme  the  screen  sharing  sessicm  begins,  so 
that  the  relevant  portion  of  the  screen  could  be  observed  by  the  guest. 

4)  Compatibility  of  Memory  Resident  Programs  :  During  our  eimeriments,  we  found 
that  the  operating  systems  crashed  more  often  than  we  expec^.  We  folt  that  this  could  be  due 
to  various  memory  resident  programs  such  as  Desk  Accessories  (DA)  on  the  Macintosh  and 
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Terminate  and  Stay  Resident  (TSR)  [»x>grains  on  IBM  PS/2.  We  eventually  dedded  to 
remove  all  such  programs  except  for  the  bare  essentials  Hire  the  Control  Parol  on  the 
Macintosh.  Though  this  compatibility  problon  could  exist  even  when  dealing  widi  a  single 
isolated  workstation,  it  manifests  itself  as  a  major  problem  in  DGDSS  context  since  one  has  to 
wo^  about  collaboration  (screen  sharing,  contrd  of  other  computers)  between  members  with 
arbitrary  configurations  of  hardware,  sc^tware  and  peripherals. 

5 )  Autosave :  Since  systems  may  crash,  we  ftnind  the  autosave  feature  of  SupetCaid  to  be 
\ery  useful.  As  many  individuals  are  working  ctxtcurrently  on  unstructured  tasks,  periodic 
save  features  could  prove  very  useful. 

6 )  Privacy/Security  Considerations  :  Most  of  all  we  felt  that  Timbuktu  does  not  do  a 
satisfactory  job  in  alerting  the  host  when  his/ho*  computer  is  being  obsoved  ro  contrdM  by  a 
gue^  It  does  put  a  small  icon  (a  face  to  indicate  being  observed  and  a  hand  on  a  mcHise  to 
indicate  being  controlled)  on  the  tt^  right  hand  comer  of  the  screen.  Howeva*.  it  does  not 
alert  die  host  with  some  sound  (say  a  b^)  or  an  alot  dialog  box  at  the  beginning  cf  a 
Timbuktu  session.  Nor  does  it  inform  you  as  to  when  additional  visitors  check  in.  We 
strongly  recommend  incorporating  permission  seddng  mechanisms  and/or  alert  features.  In 
session  #4  we  found  that  Region  2  was  observed  without  its  knowledge! 

Computerization  has  made  it  easy  to  navigate  through  a  large  volume  of  information  rather 
quickly.  But  this  has  a  drawback  especially  during  cdlabmdve  sessions.  The  observer  may 
easily  stumble  upon  stxne  sensitive  classified  information  that  he/she  is  not  sui^posed  to  see.  The 
host  should  leam  to,  better  yet,  should  be  facilitated  to  quiddy  reconfigure  the  Ivge  vtdume  of 
stored  information,  prior  to  starting  a  Timbuktu  session,  so  that  such  security^vacy  problem  are 
avoidedAninimized. 

Social  Considerations  for  Computer«Supported  Distributed  Team  Work 

Although  conqiuter-supported  distributed  team  work  is  technically  feasible,  and  in  some 
cases  easy  to  implement,  its  successful  use  may  ultimately  dqiend  on  the  manner  in  v^ch  sudi 
information  techndogy  is  incorporated  into  die  flow  of  ^oup  work.  To  the  extent  that  such 
information  technology  is  smoothly  integrated  into  an  OTganization  with  appropriate  training  and 
paiticipant  understanding,  then  distribute  teams  tiioukl  be  able  to  reap  die  bendits  that  such 
technology  permits  while  avoiding  those  situations  in  wfaidi  such  grotqt  configurations  may  be 
inadequate  for  effective  performance. 

The  screen  sharing  capalnlity  diat  was  implemented  in  die  distributed  ffvups  we  studied 
offers  an  example  of  how  the  techni^  cipability  to  screen  tiiare  may  not  be  initially  recognized  as 
useful  for  task  performance.  As  we  noted  earlier,  our  eiqierimental  groups  did  not  utilized  the 
screen  sharing  capability  at  any  great  rate.  In  part,  this  lack  of  use  can  be  maoed  to  their  relative 
unfamilianty  with  how  to  use  it,  in  ^ite  of  the  biief  training  session  that  we  had  conducted. 
Clearly,  the  siiiqde  demonstration  we  awe  of  the  Undxiktu  screen  sharing  capsl^ties  was  not 
enough  to  deve^  a  sufficient  level  of  undetiuanding  and  comfort  with  the  technique.  It  would 
aipear  that  any  iitfoimation  techiKdogy  that  involves  a  substantial  change  in  the  "normal 
procedure"  of  group  work  will  require  enough  training  to  remove  the  "strangeness"  associated  with 
working  in  such  a  fashion. 

Another  proUem  diat  can  emerge  widi  screen  sharing  capabilities  concerns  the  appropriate 
guidelines  and  norms  that  develop  concerning  the  exchange  of  information  in  this  fashion.  The 
experimental  groups  we  examined  were  "noimless"  in  this  sense,  which  may  have  contributed  to 
the  hesitation  to  use  the  screen  sharing  capabilities  that  we  obser^  (i.e.,  is  it  appicpnae  for  me  to 
peek  in  on  someone  else).  This  lack  ^  norms  was  e^teciallyprobleirotic  for  one  of  the 
expaimenud  groups  where  two  of  the  regional  managers  were  observing  die  third  widiout  his 
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being  aware  that  he  was  being  observed.  In  this  case,  neither  of  the  observing  regional  managers 
had  asked  for  permission  to  observe;  they  simply  invoked  Timbuktu  and  star^  observing.  The 
observed  manager  continued  to  go  through  his  project  information  without  regard  to  the  presence 
of  others.  Clearly,  this  kind  of  situation  can  lead  to  a  great  deal  of  discomfort  with  screen  sharing. 
Without  the  active  development  of  appropriate  norms  concerning  when  and  where  it  is  appropriate 
to  use  such  capabilities,  screen  sharing  (and  its  ability  to  convey  visual  task  information)  may  not 
be  fully  utiliz^  This  situation  also  suggests  quite  strongly  that  software  developers  (like 
Farallon)  should  make  a  greater  effort  to  ensure  that  observed  individuals  know  when  and  if  they 
are  being  observed. 

Although  we  were  not  able  to  directly  investigate  the  issue,  another  behavioral  issue  that 
may  impact  the  effectiveness  of  distributed  team  w^k  concerns  group  development  That  is,  do 
the  distributed  members  develop  w<x-king  relationships  with  odier  distributed  group  members  that 
are  different  in  character  than  those  in  face-to-face  groups.  For  example,  is  thim  less  cohesiveness 
among  distributed  group  members?  Is  it  easier  to  ignore  the  requests  of  a  distributed  group 
memter?  Does  this,  in  turn,  translate  into  less  of  a  commitment  to  the  organizatimi  as  a  whole? 
Some  of  our  observations  of  our  experimental  groups  lead  us  to  be  concerned  about  this  issue.  In 
particular,  watching  the  two  region^  managers  covertly  observing  the  third  and  the  comments  they 
made  to  themselves  about  the  others  lead  us  to  believe  that  the  lessened  social  presence  of  others 
may  serve  to  loosen  normadve  guidelines  about  appropriate  behavior.  Flaming  in  E-mail 
exchanges  is  another  example  of  this  type  of  behavior.  What  impact  this  may  have  on  the 
develt^ment  of  member  relationships  and  subsequently  on  group  productivity  is  the  empirical 
question  of  interest 

Further  Experimentation  into  Computer-Supported  Distributed  Team  Work 

Further  experimentation  on  computer-supported  distributed  teamworic  is  needed.  Our  first 
concern  in  this  section  will  be  on  further  refinements  of  the  experimental  procedure  we  developed 
and  some  extensions  of  it.  The  next  concern  will  be  a  broader  one,  encompassing  some  broader 
issues  that  should  be  studied  in  the  general  area  of  computer-supported  distributed  teamwork. 

Our  current  experimental  procedure  was  designed  to  simulate  a  task  relevant  to  USAISC. 
The  information  need^  to  solve  the  basic  budget-cutting  task  was  heavily  loaded  with  quantitative 
data.  As  initially  designed,  the  task  appeared  to  make  high  demands  on  Ae  individuals  as 
individuals  as  opposed  to  group  members  (e.g.  learning  about  the  nature  of  the  projects).  We  had 
initially  envisioned  that  by  using  the  basic  budgeting  ta^  and  creating  a  scenario  that  was  both 
technically  and  socially  complex,  we  would  set  the  stage  for  group  work  that  would  benefit  from 
the  "visual  ctuuinel"  provided  by  Timbuktu.  This  did  not  happen  to  the  extent  we  had  anticipated. 

Our  explanations  for  why  this  didn't  happen  also  happen  to  suggest  what  should  be  done  to 
alter  the  experimental  procedure.  First,  the  task  was  complex,  not  only  at  the  group  level,  but  also 
at  the  individual  level.  Individuals  had  to  both  learn  how  to  use  the  software  as  well  as  learn  about 
S  projects.  We  would  recommend  three  tactics  for  reducing  the  effect  of  this  individual  level 
complexity.  First,  provide  an  initial  training  session  whereby  individuals  could  become  facile  with 
the  software  as  well  as  getting  used  to  the  budget  cutting  scenario.  Second,  provide  all 
background  information  about  projects  on  an  a  priori  b^,  so  the  subjects  do  not  have  to  discover 
the  information  while  performing  the  task.  ThirtI,  reduce  the  number  of  projects  per  person  from  S 
to  3.  We  think  that  these  changes  would  lead  to  nxrre  time  to  share  information  and  work  out 
group  issues  rather  than  individual  issues. 

A  second  area  that  needs  woik  is  the  creation  of  intermember  conflicL  Ideally,  we  wanted 
the  group  task  to  one  of  negotiation  and  compromise,  not  sitTq}ly  sharing  information.  One  of  tire 
points  that  we  had  hoped  would  be  debared,  was  how  much  of  a  cut  each  member  should  strive 
for.  We  had  intentionally  stacked  the  priority  list  to  suggest  the  Region  3  manager  should  take 


Distributed  Computer  Supported  Team  Work 

Page  28 

larger  cuts.  Most  ^ups  apparently  adopted  a  nom  that  each  person  should  take  equal  cuts.  This 
norm  wasn't  explicitly  discussed,  but  radier  was  assumed  by  die  members  based  on  personal 
standards  of  what  would  be  fair.  We  would  recommend  stacking  the  deck  in  a  different  manner. 
Specifically,  we  suggest  that  the  regional  managers  begin  with  different  amounts  of  budget 
allocations.  Rather  than  each  being  in  charge  of  2.S  million  dollars,  have  one  person  in  charge  of 
3.5  million  and  the  other  two  in  charge  of  2.0  million.  This  should  cause  more  discussion  of  a 
group  strategy  for  allocating  cuts. 

Development  of  Alternative  Tasks 

One  might  ask  whether  the  budget-cutting  task  is  the  type  of  task  where  con^uter  screen 
sharing  will  be  of  much  advantage.  Because  the  information  is  primarily  numerical,  this 
information  can  be  communicate  accurately  by  voice.  That  is,  person  A  can  tell  person  B  that 
he/she  has  cut  3  engineering  posidons  fitim  a  budget  resulting  in  a  savings  of  $145,000  dollars. 
Not  much  is  gained  by  demonstrating  this  on  the  screen,  except  to  the  extent  tiiat  the  (4»ervers  may 
see  some  other  numb^  on  the  screen  that  might  cause  them  to  question  person  A’s  action. 

Tasks  that  have  a  stronger  requiremott  of  a  visual  component  would  obviously  benefit 
mcne  from  screen  sharing.  For  instance,  suppose  that  a  team  of  architects  has  a  set  of  preliminary 
drawings  that  it  wishes  to  discuss.  The  drawings  are  digitized  (or  initiaUy  created  throu^ 
coirq)uter  software).  It  should  be  beneficial  for  a  perstm  to  explain  their  ideas  by  using  both  phone 
communication  and  using  the  cursor  to  point  out  various  features  on  their  drawing.  There  are 
many  other  examples  of  similar  tasks  where  seeing  as  well  as  listening  is  critical  For  example, 
advertising  groups  working  on  logos,  magazine  layout,  billboards,  arid  so  on  would  be  likely 
candidates. 

We  should  note  that  many  of  the  suggested  changes  can  be  relatively  easily  incorj  t)rated 
within  the  framework  of  the  budgeting  task  software  and  scenario  that  was  developed  for  the 
current  research.  In  fact,  SupeiCard  was  selected  as  the  development  tool  expressly  for  the 
purpose  of  providing  revision  flexibility. 

Future  Research  on  Computer-Supported  Distributed  Team  Work 

As  we  successfully  address  the  technological  problems  of  linking  groups  electronically, 
we  should  begin  looking  for  ways  to  better  manage  our  applications  of  hardware  and  software. 
Any  such  attempts  at  managing  this  process  will  have  to  be  based  on  a  clear  understanding  of: 
l)group  performance  issues  in  gene^,  and  2)the  dynamics  of  computer-supported  districted 
groups  in  particular.  At  this  point  in  time,  most  of  the  attention  has  been  focused  on  the  technical 
aspects.  We  are  not  generating  the  knowledge  ctmceming  die  dynamics  of  distributed  groups 
which  will  serve  us  in  creating  or  shaping  such  groups,  improving  our  management  of  them,  or 
designing  paformance-m^roving  interventions.  There  exists  a  treed  to  be^  a  bridging  process 
which  will  translate  what  we  know  about  interacting  grotqis  and  test  its  applicability  to  distributed 
groups,  identifying  commonalities  where  generalizations  can  safely  be  nade,  as  well  as  limitations 
or  process  aberrations  which  need  to  be  noted  and  accounted  for. 

Long-term,  it  is  proposed  that  a  program  of  research  be  continued  vriiich  examines 
similarities  and  differences  between  computer-suf^xated  distributed  groups  and  face-to-faoe 
groups  along  the  major,  basic  group  process  dimCsions  such  as  communication,  motivation, 
influence,  group  development,  and  leadership.  Such  a  program  should  identify  giwp  task 
contingencies  which  affect  the  impact  of  these  dimensions  on  the  perfoimance  of  different  kinds 
con^uter-supported  groups.  For  example,  certain  group  process  factors  may  opmte  differently 
for  groups  engaged  in  information  synthesis  tasks,  conflict  resolution  tasks,  creativity  tasks,  etc. 
Fin^y,  such  a  research  program  would  study  perfomuuice-enhancing  interventions  which  would 
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identify  technical  and  managerial  means  for  facilitating  computer-supported  processes  and/or 
minimizing  dysfunctional  forces. 

For  example,  we  know  that  communications  aimed  at  a  ^up  member  expressing  a 
deviant  position  (e.g.,  counter  to  the  prevailing  group  norm)  will  increase  immediately  a^r  the 
expression  of  such  a  position,  and  vtoll  vary  as  a  function  of  the  group's  assessment  of  his/her 
likelihood  of  changing.  The  success  of  such  group  influence  attempts  is  obviously  related  to  the 
reward  and  sanction  power  the  group  has  over  the  individuaL  One  might  argue  diat  since  the 
deviation  from  the  group  norm  could  be  as  apparent  in  the  computer-suppmted  distrilnited  group 
as  in  the  face-to-face  group,  the  changes  in  communication  pattons  to  die  target  person  ought  to  be 
replicated  in  computer-supported  groups.  However,  to  the  depee  that  interacting  groups  are  part 
of  the  immediate  environment  for  the  ^viant,  being  more  readily  able  to  express  displeasure,  use 
non-verbal  cues,  and  even  ostracize  such  a  member,  one  might  argue  that  such  groips  will  be  more 
effective  than  computer-supported  groups  in  obtaining  conformity. 

In  closing,  it  is  becoming  common  for  Management  Information  Systems  researchers  and 
"groupware"  software  development  people  to  talk  atout  a  software  "toolbox"  from  which  users 
can  choose  programs  and  modules  that  will  help  them  with  a  particular  individual  or  group  task. 
We  are  suggesting  that  the  dstributitxi  of  group  members  can  quite  likely  change  the  fundamental 
nature  of  group  processes  and  hence  software  toolboxes  which  are  partly  responsible  for  the 
change  certainly  don't  address  the  consequences  of  the  change.  Tho^ore,  group  management  or 
intervention  strategies  may  eventually  be  needed  in  conjunction  widi  computer-support^ 
distributed  groups.  These  recommendations  may  pertain  to  modifications  in  the  computer- 
supported  work  environment,  supplementary  group  development  efforts  before  or  during  group 
performance  episodes,  or  observational  guides  for  identifying  dysfunctitmal  group  events.  These 
strategies  shodd  be  based  on  the  results  of  empirical  studies. 
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Table  1 

Summary  Budget  Results  for  All  Regions  Across  All  Sessions 


Session  1  Summary  Session  2  Summary 


laitial 

Region  1 
Revised 

%Cnt 

Initial 

Region  1 
Revised 

%Cnt 

AlOOO 

710 

577 

AlOOO  1 

fsm 

595 

585 

■m 

A30QO 

580 

485 

16.4 

A3000 

580 

0 

100.0 

A4000 

415 

315 

24.1 

A4000 

415 

415 

0.0 

ASOOO 

210 

200 

4.8 

A5000 

210 

0 

100.0 

Total 

2510 

2162 

13.9 

Total 

2510 

1670 

33.5 

Initial 

Region  2 
Revised 

%Cat 

Initial 

Region  2 
Revised 

%Cnt 

BIOOO 

430 

388 

9.8 

BIOOO 

430 

345 

19.8 

B2000 

822 

352 

57.2 

B2000 

822 

642 

21.9 

B3000 

375 

365 

2.7 

B3000 

375 

330 

12.0 

nm 

563 

456 

19.0 

563 

406 

27.9 

BSOOO 

310 

286 

in 

B5000 

310 

310 

0.0 

Total 

2500 

1847 

26.1 

Total 

2500 

2033 

18.7 

Initial 

Region  3 
Revised 

%Cttt 

Initial 

Region  3 
Revised 

%Cnt 

CIOOO 

265 

265 

0.0 

CIOOO 

265 

263 

0.8 

922 

922 

0.0 

922 

922 

0.0 

C3000 

628 

628 

0.0 

C3000 

628 

628 

0.0 

140 

73 

47.9 

140 

113 

19.3 

C5000 

545 

0 

100.0 

C5000 

545 

0 

100.0 

Total 

2500 

1888 

24.5 

Total 

1926 

23.0 

roMlf 

7510 

5897 

21.5 

Rtgl  T0talt 

7510 

5029 

25.0 
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Table  1  cont. 


Session  3  Summary 


RefioB  1 


Initial 

Rcviaad 

%Cnt 

AlOOOl 

28.9 

232 

595 

361 

39.3 

fES. 

580 

451 

22.2 

A4000 

415 

320 

22.9 

210 

200 

4.8 

Total 

2510 

1837 

26.8 

Region  2 

laitial 

Reviled 

%CBt 

BIOOO 

44.2 

822 

42.8 

375 

265 

29.3 

BS3 

563 

451 

19.9 

B5000 

310 

274 

11.6 

Total 

2500 

1700 

32.0 

RegioB  3 

Initial 

Reviled 

»Cat 

CIOOO 

265 

233 

12.1 

C2000 

922 

742 

19.5 

C3000 

628 

535 

14.8 

C4000 

140 

99 

29.3 

C3000 

545 

342 

37.2 

Total 

2500 

1951 

22.0 

Session  4  Summary 


Rc|ioa  1 


Initial 

Reviled 

%Cat 

AlOOOl 

710 

685 

■K 

595 

537 

415 

415 

0.0 

210 

210 

0.0 

Total 

2510 

2427 

3.3 

Initial 

Region  2 
Reviled 

%CBt 

BIOOO 

430 

305 

29.11 

TTT? 

822 

822 

375 

375 

563 

563 

B5000 

310 

310 

0.0 1 

Total 

2500 

2375 

5.0 

Initial 

Region  3 
Reviled 

%Cnt 

CIOOO 

265 

235 

11.3 

C2000 

922 

922 

0.0 

C3000 

628 

628 

0.0 

C4000 

140 

0 

100.0 

C5000 

545 

340 

37.6 

Total 

2500 

2125 

15.0 

Jt«f3  TeMlc  7510 


5400 


20.9  ntfO  T0M$  7510 


0927 


7.0 
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Table  2 

Multiple  Regressions  for  Modeling  Budget-Cutting  Process 


r2 

Initial 

Budget 

Otgtnizaiiaatf 

Priority 

Beta  Weights 

Number  of  Number  of 

Self  Progects  that 

Priority  Dcpendoolt 

Ejects  4 
Depended  On 

Sessions  1-3 

.14 

.14 

.32 

.39 

-.06 

.22 

Session  1 

.47 

.32 

.65 

.75 

-.11 

.26 

Session  2 

.05 

-.09 

.05 

.18 

-.06 

.12 

Session  3 

.60 

.55 

.58 

.50 

-.01 

.56 

Session  4 

.80 

-.30 

.66 

.62 

.37 

.38 
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Table  3 

Summary  of  Project  and  Budget  Line  Item  Accesses 


Session  1 

Number  of 

Project  Accesses 

Number  of  Line 
Item  Accemes 

Regicm  1 

25 

54 

Regi(m2> 

12 

9 

Re^on  3 

-22 

-12 

Mean 

19.7 

253 

Session  2 

Region  1 

16 

15 

Region  2^^ 

2 

4 

Region  3 

31 

Mean 

11 

12 

Session  3 

Region  1 

17 

56 

Region  2 

31 

78 

Region  3 

-66 

Mean 

28 

66.7 

Session  4 

Region  1 

23 

43 

Region  2 

8 

7 

Region  3^ 

—6 

-15 

Mean 

123 

21.7 

43  mBHUes  of  w(xk  dne  to  cnsh. 
(’Lost  SO  miiHaes  of  weak  doe  10  cnuh. 
^Lost  64  mimues  of  wofk  doe  10  cmlL 
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Figure  1 

Taxonomy  of  GDSS  Environments 
(firom  Dennis,  et  al.,  1988) 


Sites 

GROUP  PROXIMITY 


Mmm^ement  Research  Lahoraiory  (MRL)  Floor  Plan 


Oneway  Minor 


Disiributed  Compuier  Supponed  Team  Woric 

Plage  37 

Figure  3 

Illustration  of  a  Distributed,  Interacting,  Screen  Sharing  Team  Configuration  with 
Remote  (dial*in)  Member  (Network  and  Remote  Timbuktu) 


Draft  Document:  12/28/B9,  4:161^ 
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Appendix  A 

Omega  Project  Priorities  and  Classifled  Information  for  All  Regions 


OMEGA  INCORPORATED 

New  R&D  Project  Priority  List 


REGION  1 

Project  #  Priority 

AlOOO 

3 

A2000 

9 

A3000 

8 

A4000 

11 

A5000 

1 

REGION  2 

Project  #  Priority 

BIOOO 

13 

B2000 

4 

B3000 

7 

B4000 

6 

B5000 

2 

REGION  3 

Project  #  Priority 

CIOOO 

14 

C2(X)0 

5 

C3000 

12 

C4000 

10 

C5000 

15 

Title 

MPED  Records  Maintenance 
no  Micrographics 

Voice  Acdvat^  Computer  Communications 
Optical  Digitizer  Analyzer 
LPID  Di^lay 


Title 

Prototype  High  Sp^  CPU-Link 
Large  Scale  Switching  Software 
Enhanced  Air  Traffic  Ccmtrol  System 
Scheduling  and  Reservations  Software 
Credit  Reporting  Software 


Title 

Satellite  Relay  Prefect 
Fiber  Optic  Enhancement 
VOC  Visual  Thmsmitta^ 

Network  of  the  Future 

RadioA'elephone  Computer  Communications 
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OMEGA  INCORPORATED 
Region  1-Classified  Information 


Project  AlOOO-  MPED  Records  Maintenance 

*♦*•**♦**♦  CLASSIFIED  INFORMATION  ♦♦♦***♦*** 
OMEGA  PrkHity--  3/15  Your  Region  Priority-  4/5 


This  work  is  one  of  the  outcomes  of  several  strategic  planning  sessions  concerning  how  die  MPED 
division  could  cut  costs  and  run  a  more  competitive,  leaner  C9)erati<Mi. 

PERSONNEL 

Personnel  for  this  project  consists  of  system  analysts,  programmers  and  clerical  assistance. 

Two  of  the  full  time  programmers  are  critical  to  the  development  of  this  project  in  that  diey  bring  special 
skills  that  are  hard  to  replace. 

Two  of  the  half  time  programmers  are  also  critical  to  this  project  In  addition  to  being  hired  qrecifically 
to  work  on  this  project  their  time  is  also  being  shared  on  project  #  C4000. 

The  overtime  allocation  represents  a  government  requirement  that  personnel  budgets  reflect  an  anticipated 
overtime  pay  allocation,  even  thou^  project  manbm  are  encouraged  to  take  conq)  time.  Past 
experience  has  suggested  that  about  50%  of  this  money  is  not  spent. 

The  temporary  hire  reflects  the  hire-back  of  a  government  retiree  that  used  to  work  in  a  particular  office. 
She  had  special  knowledge  relative  to  the  reconl  maintenance  project  and  dius  was  hired  back  even 
though  she  "retired"  after  30  years  in  government  service. 

The  pan  time  assistants  are  usually  hired  from  the  local  ctdle^.  They  sometimes  become  full  time 
employees  after  graduation.  They  work  about  20  hours  per  week  to  do  some  suppon  woric  for  the 
programmers. 

EQUIPMENT 

Woricstations,  the  networicing  hardware  is  of  no  imntediate  use. 

The  Superscreen  Displays  are  very  important  to  die  project  Although  it  is  possible  to  use  the 
Superscreen  displays  without  the  No^Masters,  it  is  difficult  to  get  good  test  restdts  for  purposes  of 
determining  aunliary  requirements. 

TheSuperAcoessBit  Accelerator  is  not  necessarily  needed  for  this  project  When  this  project  is 
implemented,  the  accelerators  would  be  availidite  due  to  a  central  purchase.  However,  anraher  project 
CSOOO,  deqieraiely  needed  the  accelerator  for  its  progress,  but  did  not  have  funding.  You  were  able  to 
justify  slipimg  it  into  your  project  budget 


DissSNMed  OmV****  T'Bmb  Wofk 
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Project  A2<K>0-  IPO  Micrographics 

*******««*  CLASSIFIED  INFORMATION  ********** 


OMEGA  ftiority--  9/15  Your  Regkm  Priority-  1/5 


This  prcgect  depends  on  the  coiiq)letion  of  project  AlOOO. 

PERSONNEL 

Need  evoybotfy  on  board  to  conqdete  this  work  in  time  to  feed  into  project  AlOOO. 

EQUIPMENT 

Anidyzersot^  are  absolutely  neoessBiy.  Woric  stations  are  diacretionaiy. 

MATERIAL  &  SUPPLIES 

Technical  hardware  should  not  be  touched.  Office  supplies  are  cuttable. 

TRAVEL 

Site  travel  is  high  priority.  Headquarters  travel  is  second  priority.  Conference  travel  is  low  priority. 
SUBCONTRACTOR 

Subccmtractorisbeingusedfor  die  first  tioM  with  projects  under  your  management  Their  work  is  on 
some  RAD  type  work  which  would  be  an  enhanoement  to  the  basic  mission. 


Project  A3000-  Voice  Activated  Computer  Communicatiou 

**********  CLASSIFIED  INFORMATION  ***•****•* 

CHdEGA  Priority"  8/15  Your  Rq^km  Marity-  V5 

This  project  is  moving  some  basic  research  dole  to  commercial  qiplications.  It  prob^y  woidd  be  used 
in  both  Projects  B3000  (Enhanced  Air  Traffic  Control  Systems)  and  B4000  (Scheduling  and  Reservation 
Systems). 

E(2UIPMENT 

The  conqwaers  and  teiqihones  are  gntendrepiacenaent  items.  Tire  voice  recofnikioniiiodiiies  are 
essential. 

Project  A4060-  Optical  Digitiser  Aiuilyaer 

**«*•*****  CLASSIFIED  INFC)RMATIC»I  ********** 

CXdEGA  Priority-  11/15  Yotr  Region  Priority-  3/5 


This  project  is  aematty  the  oompMon  of  wodcdret  has  been  foinf  on  for  4  years.  Ahhongh  it  has  a 
different  pwjeantnaber  dam  bAee,  it  is  redly  centinuaiinn  mwsey.  To  drop  fob  prqjecttt  dm  point 
would  srewi  diat  4  yean  wordi  of  progress  wodd  be  viitualfy  lost  and  the  cmidayees  would  leave 

(dreoigineen). 
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Project  A5000-  LPID  Display 

***♦**•***  CLASSIFIED  INFORMATION  •*♦*♦**•** 


OMEGA  Monty-  1/15  Your  R^km  Priority-  5/S 


This  pnigect  iqtresaits  fundamental  research  by  one  of  the  ino6t  hi^y  reflected  oompi^  sdoitists  in 
the  worid  (who  work  for  mini  Systems).  Thou|^  this  ixcgect  does  not  have  any  immediate  coinmacial 
implications,  it  may  eventually  novide  the  basis  for  a  much  better  visual  m^lay  on  large  systems. 
Specifically,  another  piojec^  B3000  (enhanced  air  traffic  oontrcd  system)  is  etqiected  to  use  some  of  die 
d^ek^ments  finom  this  project 

PERSONNEL 

Because  most  woik  is  being  done  by  contractor,  cuts  in  ancillaiy  personnel  (non  professional)  are  ck. 
EQUIPMENT 

SupeictMiiputer  time  is  absolutely  essential. 
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OMEGA  INCORPORATED 
Region  l-ClassiHed  Information 


Project  Project  BIOOO-  Prototype  High  Speed  CPU>Link 

******♦♦♦♦  CLASSIFIED  INFORMATION  ****♦****♦ 


OMEGA  Priority-  13/15  Your  Rcgk»  ftiority-  3/5 


Hus  project  has  been  heavily  supported  in  the  patt^vke-prestdents  in  your  con^Muy.  AUiouglitfie 
total  amount  of  money  is  rather  si^,  the  payoff  if  it  is  successful  could  be  trefnendous. 

reRSONNEL 

Full  time  engineeis  should  not  be  cut  This  project  was  used  to  hire  top  notch  pec^le.  In  addition, 
consultant  is  very  important  to  project 

TRAVEL 

Consultant  travel  can  obviously  be  cut  if  consultant  is  cut 


Project  Project  B2000>  Large  Scale  Switching  Software 

**********  CLASSIFIED  INFORMATION  ********** 


OMEGA  Priority-  4/15  Your  RegUm  Priority-  5/5 


The  project  has  several  justifications.  First  even  though  it  has  a  priiiiatyinarimt  in  die  oomoxrcial 
arena,  it  also  has  potential  payoffs  for  some  odier  internal  projects  (e.g..  Project  CIOOO). 

PERSONNEL 

The  4  fuUtuneptt^ranmiersdeinonstratBd^feraat  talents.  To  lose  any  of  them  would  mean  diat  it 
wmild  be  difficult  to  meet  project  deadfines. 

EC^JIPMENT 

The  work  stations  me  not  absolutdy  necessary  but  do  r^iesCTt  a  fiadier  modernization  of  the  labs 
equqmirat  High  level  PCs  and  memory  q^gtade  are  essential  to  project 

SUBCONTRACTORS 

QuickSys,  Inc.  has  been  know  to  ovenun  its  budget  Tliey  do  eaceSent  innova^  work  udiich  is 
nreplaceiMe,  but  past  experience  suggests  dwt  di^  will  au  for  an  eMensaon  in  time  and  money. 
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Project  Project  B3000-  Enhanced  Air  Traffic  Control  System 

**********  CLASSIFIED  INFORMATION  *•♦*•***♦* 


OMEGA  Priority-  7/lS  Your  R^km  Monty-  VS 


PERSONNEL 

Technical  assistant  are  typically  ooUege  students.  For  tfus  type  of  work,  they  are  fiequen^  laid  off 
when  budgets  are  tight 

EQUIPMENT 

T^  enhanced  PCs  are  pait  of  a  general  effort  to  upgrade  equtyment 
SUBCONTRACTORS 

mini  Systems,  bic.  lus  become  a  preferred  subcontractor  since  di^  were  recently  granted  NDnority 
Business  status. 


Project  Project  B4000-  Scheduling  and  Reservation  Software 

**********  CLASSIFIED  INFORMATION  *♦*♦*•**•* 


OMEGA  Priority—  ti/lS  Your  Region  Mority-  1/S 


This  project  must  move  forward  if  it  is  to  be  worth  anything.  There  are  conqtedtorswoiidng  on  similar 
projects. 

ICRSONNEL 

Lead  programmer  position  is  less  inqiortant  than  die  other  professional  posidons. 

EQUIPMENT 

Enhanced  PCs  will  be  necessary  on  this  noject  aldiou|h  h  is  possible  to  borrow  from  other  prajects. 
Having  dedicated  PCs  increases  ptoducdvity. 

SUBCONTRACTORS 

The  subcontractor  work  is  not  vital  because  diey  are  working  on  a  feature  dun  is  probaUy  several  years 
away  from  viability.  However,  a  member  of  your  Board  of  Duecton  is  a  large  sharehcdder  in  LOL 
Sysrems,  Inc. 


Project  Project  B5000-  Credit  Reporting  Software 

**********  CLASSIFIED  INFORMATION  •**•••♦••* 


C^dEGA  Priority-  2/15  Your  Rq;ion  Pnority-  4/5 


PERSONNEL 

All  perioraiel  and  overtime  are  essential  for  moniioiingworic  of  subcontractor. 
EQUIPMENT 

Eitooed  PC  is  discretionary  and  rqiiaoement  equqiment 
SUBCONTRACTORS 

All  work  on  dds  inogect  is  being  conducted  by  die  sttbcorttractor. 
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OMEGA  INCORPORATED 
Region  3-Classified  Information 


Project  CIOOO'  Satellite  Relay 

****♦•*♦♦*  CLASSIFIED  INFORMAnON  •*•*•♦••** 

OMEGA  lYiority-  14/15  Your  Region  PrioriQr-  2/S 

This  pttiject  will  also  be  used  in  Project  CSOOO  whidi  is  dte  RadiQ/rdq)hoiie  Communication  Project 


Project  C2000-  Fiber  Optic  Enhancement 
♦♦**♦**♦**  CLASSIFIED  INFORMATION  **•**•♦*•* 
OMEGA  Prioiity-  5/15  Your  Region  ftiority-  4/5 


This  project  is  extremely  imptwtant  to  your  company.  If  ]»Dgress  is  made  in  this  area,  it  might  mean 
your  company  will  have  the  coo^etitive  edge  on  fi^  optic  transmission  for  years  to  come.  Thisis 
expected  to  be  a  multi-year  project 

lliis  project  is  also  expected  to  have  an  intact  on  C4000  which  is  "Networic  of  the  Future"  as  well  as 
project  AKIoO  which  is  "Vdee  Activated  Computer  Communications". 

PERSONNEL 

The  personnel  are  expected  to  be  hand-picked  expats  from  all  over  the  ooaqMny. 

About  half  technical  assistant  positions  would  go  to  college  stodenis.  The  odier  half  would  go  to 
experienced  technicians  who  would  be  more  inqxxlant  to  die  progress  of  die  project 

EQUIPMENT 

Tto  remains  an  unqiecifiedexpenAture.  In  the  past  sudi  a  large  unqiecifled  expenditures  would 
contain  40^0%  rqilacement  equipment 


MATERIALS  &  SUPPLIES 

Tedmical  hardware  should  not  be  toudied.  OfiicesiqiplieaseciitMUe. 
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Project  C3000-  VOC  Visual  Transmitter 

**********  CLASSIFIED  INFORMATION  *♦*•••*••* 

OMEGA  Priority-  12/15  Your  Regkm  MoriQr-  1/S 


Oncethecommncialtransnassionliiieschany  over  to  grade  media,  die  VOC  Visual  transmitter 

will  be  obsolete.  This  project  has  been  authnized  for  fumling  for  die  piytS  years.  It  has  always  been 
cut  before  die  mon^  was  actually  allocated.  A  rttknale  for  &s  project  is  diat  Project  BIOOO  will  require 
such  hi^  ^peed  transmission. 

PERSONNEL 

These  positions  have  not  yet  been  filled.  In  fact,  the  SuboontractOT  was  going  to  be  hired  first  and  dien  a 
project  team  e^ablished  diat  was  conqiatible  widi  die  subcontractor. 

EC^JIPMENT 

All  (Otitis  equipment  is  necessary  if  any  progress  is  to  be  made  on  diis  project  The  miscellaneous 
electronics  are  a  general  category  that  inigiit  represent  non-ciitical  expe^tures. 

MATERIALS  A  SUPPLIES 

High  density  cable  is  not  typically  available  unless  it  is  special  ordered  for  a  project 
SUBCONTRACTORS 

LCX..  Contractors  tends  to  employ  some  of  the  recent  retirees  from  your  company. 


Project  C4000-  Network  of  the  Future 
**********  CLASSIFIED  INFORMATION 
OMEGA  Priority-  10/15  Your  Region  Priority-  5/5 


Thisprqject  is  sui^xised  to  result  in  a  better  understanding  of  what  die  marketplace  wants  in  computer 
netw^  featines.  Specifically,  it  is  supposed  to  jneparerqiofts  that  will  be  somewhat  useful  in  Projects 
B5000  (Credit  Bureau)  and  B4^  (Sch^uling  a^  Reservations).  The  project  poup  is  a  unique 
collection  of  engineers  and  marketing  qiecialistsuriio  are  knowledgeable  about  clients.  There  should  be 
suggestions  concerning  what  niches  of  the  market  this  oonmuiy  can  fill  in  the  n«ct  decade.  &ipart,diese 
nfohes  trill  dqptmd  on  some  outcomes  of  R  ft  Dinojects  which  are  on-gmng  in  diis  company. 

PERSONNEL 

Market  researchers  tend  to  be  profosson  and  grachiate  students  from  a  local  univetsiQr.  Theptyfor 
engineeis  would  not  result  in  hiring  any  new  people,  but  rather  be  "sabbatical-(ype*  ^y  for  some  older 
employees. 

TRAVEL 

IMdiout  knowing  who  die  personnd  will  be,  it  is  hard  to  determine  tow  mudi  travel  will  actually  be 
necessary. 


Project  C5000*  Radio/Telephone  Computer  Communications 

**********  CLASSIFIED  INFORMATION  ••♦••••••• 
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OMEGA  Priority--  15/15  Your  Region  Monty—  3/5 


This  project  has  bera  suggested  for  several  years,  but  has  never  been  funded.  This  is  probably  the  rinal 
year  that  dm  project  will  be  worduiriiile  (be^se  ci  anticqtated  progress  of  competitors). 

PERSONNEL 

The  engineers  picked  to  work  on  this  project  are  all  top  rate  people.  If  dtis  project  is  cut,  you  would 
probably  lose  diem. 

The  technical  assistants  are  college  students  iMio  are  actually  on  internship  and  are  not  critical  to  project 
success. 

ECyjIPMENT 

Computers  are  leplaconent  equipi^t  but  would  be  seen  as  perks  for  die  engineers  working  tm  the 
project  The  modular  radios  are  critical  to  die  success  of  the  project 
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Appendix  B>  Screen  1 

Task  and  Scenario  Introduction  Screen  Displays 


Omega  Incorporated  -Region  1 
Budget  Manager  Briefing 


Distributed  Computer  Supported  Team  Work 
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Appendix  B-  Screen  2 


6o  Back 


Distributed  Computer  Supported  Team  Work 
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Appendix  B-  Screen  3 


Distributed  Computer  Siq^ported  Team  Work 
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Appendix  B-  Screen  4 


DiMribum  Conpuier  Si^ported  Team  Woric 

FVeSl 


Distributed  Computer  Suppono-I  Team  Work 
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Appendix  B*  Screen  6 


You  and  the  other  two  Regional  Budget  Msmagers  have  the  tough  job  of 
reaching  a  collective  agreement  on  the  budget  cuts. 


Dittibuled  Computer  StqjpaUBd  Team  Woric 

Pa^c  53 


Appendix  B-  Screen  7 


Distributed  Computer  Suppt-  ■  :  ^  Work 

*-^gc54 


Appendix  B-  Screen  8 


Individuals  in  the  Regional  Budget  Manager  position  (your  job)  tend  to 
stay  there  only  a  short  time  (usually  it  is  the  first  step  up  the  corporate 
ladder).  Ther^re  the  incumbents  tend  to  be  inexperienced  and  not  know 
that  much  about  the  projects  or  the  people  who  might  work  on  them. 


Distributed  Cooiputer  Suppoded  Team  Woifc 

Pa^c  55 


Appendix  B*  Screen  9 


Go  Back 


Distributed  Computer  Supp 


■  •■'m  Woric 
<  aae  56 

Appendix  B-  Screen  10 


Ditfribuied  Computer  Siyported  Teem  Woilc 

Ps«e57 


Appendix  B>  Screen  11 


Recess  Budget  Software 


DifiribaiBd  ConpoiBr  SufipofiDd  Tcm  Worit 

ft(e58 


Appendix  C 

Budgeting  Task  SuperCard  Script  Examples 


i^roject  Script 


Anpose;  Tins  script  executes  when  die  project  is  first  begniL  bellows  die  pn^tammer  to  set  ceitain 
parameters  for  the  project  befim  it  allows  the  user  to  do  uydung.  bidiiscase,weusebto: 
affect  die  di^ay  of  die  menubar,  the  di^ay  format  of  nw^iers,  conmandkey  functions, 
disable  the  arrowkeys,  trap  fin  bmtcm  presses,  trap  for  window  closes,  trap  for  classified 
inftnmation  access  button  presses,  and  to  summarue  trap  infotmation  whm  die  project  is 
closed  (quit). 


On  Startup 

hide  menubar 

set  die  numberifomaat  to  0 

End  Startup 

On  MenuKey  CX)MMAND_KE Y 

If  COMMAND.KEY  is  "M”  then  Set  visible  oi  msg  to  not  visiUe  of  msg 
If  COMMAND  KEY  is  "Q"  then  Close  all  windows 
If  OOMMAND_KEY  is  "X"  then  Cut 
If  COMMAND  KEY  is  "C "  then  Copy 
If  COMMAND  JCEY  is "  V"  then  Paste 

If  COMMAND_KEY  is " "  then  Set  visible  of  menubar  to  not  visible  of  menubar 
End  MenuKey 


onarrowkey 
endanowkey 
on  trap 

gl(^  trapFile,  Uank 

put"  iMitton pressed  " into temptext 

write  die  long  time  A  blank  A  the  short  name  of  target  A  leapiext  A  Renaon  to  file  tnpFile 
endtnqp 

ontrapC  -- used  to  trqi  a  window  Cloae 
global  trari^  bknk 
put"  Wmd^ Closed  ”  into tengitext 

write  die  long  time  A  blank  A  the  riioit  name  of  taiget  A  temptext  A  Return  to  file  tnpRle 
endtrapC 

on  tnmClassifled  •>  when  die  classified  budon  is  dkhed 
glwal  trapRle,  btauA 

put"  Gassifi^  button  was  clicked  to  see  "imo  temptext 
write  the  loM  time  A  blank  A  temptext  A  the  dxxt  name  of  target  to  file  tiapRle 
end  trapClassimd 


on  closePic^t  ••  t*************************************************************** 

set  cursor  to  busy 

GloM  tnq^i^,  button.Count,  blank 

Global  R^ised_Regk>n J2,  Revised_Reaon_3.  orifinaLooont.  levisedLoount 

Global  alOOOjcount ,  a2000_count .  a^^.eount .  •4(XXLooiint ,  aSOOOLoount 

Global  pal. pa2,pa3,pa4,paS  -personnel 

Global  eal,  ea2,  ^  -  equipment 

Global  null,  ma^ina3,ii^,inaS  --  materials  and  siqyplies 

Global tal, ta2. ta3, ta4, ta5  --travel 

Global  sal,  sa2,  aa3,  sa4,  sa5  -  subcontractors 

pm "  ******************41***  Summary  of  Session  Begin  **•••*•"  into  tenqnext 
Write  Return  ft  Return  &  teoaptext  &  return  &  return  to  file  npfile 
Write  the  long  time  ft  Return  ft  Return  ft  Return  to  file  tn^iue 

writeln 

put  "No.  (rf  times  Region  2  revised  s  "  into  temptext 
write  tetrqNext  ft  Revised_Region_2  ft  Return  to  file  tnqiHle 

put  "No.  of  times  Repcm  3  revised  «  "  into  temptext 
write  tenqxext  ft  R&^sed_Region_3  ft  Return  to  file  trapRle 

writeln 

put  "No.  of  times  button  fOT  chan  Original  clicked*  "iruotempiext 
write  temptext  ft  originaljcount  ft  Re^  to  file  tnqiRle 

put"  No.  times  button  for  chan  Revised  clicked*  "iniotenptext 
write  leirquext  ft  revisedjcount  ft  Return  to  file  tnqrHle 

writdn 

put  ”  AlOOOjcount  ”  into  tanpteA 

write  teirqrtext  ft  alOOO.count  ft  Return  to  file  tnqrRle 

put "  A2000joount  "  into  teitmtext 

write  tetrqrtext  ft  a2000_oount  ft  Return  to  file  trapRle 

put  ”  ASOOOjoount  "  into  tonptext 

write  temptext  ft  aSOOO.count  ft  Return  to  file  trqiHle 

put "  A4000Loount  "  into  tenmtext 

write  temptext  ft  a4000_oount  &  Return  to  file  tnqrRle 

put "  ASOOOjoount  "  into  teitmtext 

write  tonpiext  ft  aSOOO.count  &  Rennn  to  file  trqiHle 

writeln 

put "  Penonnel^uqmient/M&SriVavel/SuboontrBCtarB  info  for  AlOOO into  temptext 
write  tenqxext  ft  Return  to  file  triqiHle 

writepal  ft  Uankfteal  ftblankftmal  ft  Uankfttal  ftblankftsal  ft  return  ft  Return  to  file 
trq^e 


put "  Personncl/Equqmaent/MftS/Ilravel/Suboootractors  info  for  A2000 into  temptext 


write  templext  &  Return  to  file  trqiFile 

r~'  write  pa2  &  blaok  ft  ea2  &  blank  ft  ma2  ft  blank  ft  ta2  ft  Hank  ft  sa2  ft  return  ft  Return  to  file 
trapFUe 

put "  Peiaoniid^Gpvnaent/MftS/lVanrel/Subooatiacton  info  for  A3000 into  tenyiext 
write  tnofiiext  ft  Mturn  to  file  tr^file 

write  pa3  ft  Uank  ft  ea3  ft  blank  ft  notaS  ft  blank  ft  ta3  ft  Umk  ft  sa3  ft  return  ft  Retnm  to  file 
tnqiFile 


put "  Persoond/Bmqnient/MftS/Travd/SubcoatractQn  info  for  A40QO into  tenqNext 
write  teaytextA  Return  to  file  tn^ile 

write  pa4  ft  Uuik  ft  ea4  ft  blank  ft  nia4  ft  bUmk  ft  ta4  ft  blank  ft  sa4  ft  return  ft  Return  to  file 


put "  Peraonnd^^pment/MftS/Travel/SuboontracKxs  info  for  A5000 into  tenqptext 
write  tenqjtext  ft  Retun  to  file  traff  ik 

write  pa5  ft  blank  ft  eaS  ft  blank  ft  nu5  ft  blank  ft  ta5  ft  blank  ft  sa5  ft  return  ft  Return  to  file 
trapHle 

wrileln 

writeln 

close  file  tnq^^ 

endcloseProject 

on  wrileln 
Global  tiapHle 
write  return  to  file  tnqiFile 
end  writeln 


Wbdow:  Budjft  AliocatioBS  I 


Omega  Bnigat  AlloeiHons,  90-91 

(in  Thousands  of  DoNars) 

•rtataal 

Ravtood 

Railaal* 

2500 

2500 

RagloRZ 

2500 

2500 

RaglMl 

2500 

2500 

Total 

7500 

7500 

Script  for  "Rtvifcd  Field  2" 
oncloaci^eld 

global  Rwl,  ieg3,  prol.  pra2,  fiioS.  stan3 

putcadndkI'ileviaedRegioo  Tinioiegl 

put  card  field  ”Reviaed  Re^on  2"  into  11^ 

pid  card  field  "Reviled  R^kn  3"  fatto  r^ 

put  0i^l4c^4r^)  into  card  fidd  "RemdR^ioD  Total" 

Global  trqjHle,  Hank,  ReviaedLRegioi|_2  >-***  bi^ 
pot(ReviiledUbM;ioQ_2+ 1)  into  Revised Jl^ionJ2 
Kt  "ReviaedUPi^"  intoFiddjuBne 
Write  die  long  time &Uank  A  Held_name  ft  Return  to  file  tnqiFile 
Revised  R^ion  2  «  ”  intoiemptext 

riteblankftUi^fttempiextftrDgz  ftRetmitofiletnpHle  •-***end 

put  (cd  field  "Revised  Region  Vfed  field  "Revised  Region  Total")  -n 

*  3d)  into  prol 

put  ((cd  fiw  "Revised  Regkm  2"/od  field  "Revised  Region  Total") 
*^)intopro2 

put  ((^  field  "Revised  Region  3"/od  field  "Revised  Region  Total") 

*  360)  into  pfo3 

put  die  round  df  prol  into  prol 
put  die  round  of  pro2  into  pro2 
put  the  round  of  pro3  into  pro3 

put  the  found  of  (ptDl/3.6)  ft  "%"  into  card  field  "Rl"  of  cd  "RPiot"  -• 
of  window  "Revised  AUooadon" 

put  the  round  of  (pR^.6)  ft  "%"  into  card  field  "R2"  of  cd  "RFIot"  -■ 
of  window  "Revised  Alkx^on" 

put  the  round  of  (pr>3/3.6)  ft  "%"  into  card  field  "R3"  of  cd  "RFIol" -• 
of  window  "Revised  Allocation" 
put  prol  4- pro2  into  start3 

set  me  staitAi^  of  gn^c  "Regl"  of  window  "Revised  Allocation"  to  0 
set  die  aicAn^  of  grq^  "R^r  of  window  "Revised  Allocation"  to  prol 
set  the  staitAn^  of  gnmhic  "Ri^"  of  window  "Revised  ADocaiion”  to  prol 
setthearcAn^of  m^c  "R^"  of  window  "Revised  Allocation”  to  pro2 
set  die  startAMle  of  gnmhic"R^"  of  window  "Revised  Allocation"  to  siMtS 
set  die  arcAm^  of  gnuw  "R»"  of  window  "Revised  Allocation"  to  pro3 
enddoseField 

on  returolhReld 
sendtabKiw 
endretumbiFteld 

Script  of  Button  to  show  the  "Revised  Allocation"  plot 

onmooseUp 

setdiecmortod 

send  doieHdd  to  cd  field  "Revised  R^on  2" 
open  window  "Revised  Allocation" 
set  the  cursor  to  1 

Global  RevisedLcount 
putRevisedLoount-f  1  into  RevisedLcount 
trip 

endmouseUp 


Script  for  Mtow  to  fo  to  SpccUk  Fr^locte  (AIMS  tmiplt) 


Piffpooe: 


Sen 


oDmomriJp 

fBt  the  short  BUDB  of  the  tarpet 


DiMriboied  Compuier  Sinnr^ 


set  the  name  of  window  id  1Q2  to  Hefion  1  Project#  "  &  it  -i 
&  "  Managerr  &  line  1  od  field  "Manager” 
open  window  id  102 

Global  alOOOjcount,  tiwE^e 
Write  Return  to  file  trapl^ 
pot  alOOOjcount  -f  1  into  alOOO.count 
trap 

endmouseUp 


Windows:  Original  and  Revised  Allocations 


1 


Purpose:  These  two  windows  are  used  to  di^day,  at  the  discretion  of  the  user,  the  relative  distribution 
of  die  overall  budget  across  the  regioos.  The  original  allocations  pkk  does  not  change  and 
reflects  die  differences  in  initial  bixiget  aDocaiioos.  The  revised  allocation  plot  changes  widi 
ev^  change  diat  is  made  to  the  buckets  of  the  proiects  controlled  by  the  manager  or  to  die 
revised  budget  amounts  indicated  for  die  odierr^ions  in  the  budget  allocation  window. 


Original  Allocationa 


Roviaad  AHoeadona 


Region 
■  l  33% 
G2  33% 
Q3  33% 


Window:  Communications 


Purpose:  This  window  was  set  up  to  contain  the  programming  dutt  would  allow  die  user  to  easily 
invoke  Umbuktu:  a)  to  observe  die  screen  of  one  of  their  firilow  Regional  Maoagers  (h^ 
section  of  the  window),  b)  to  control  odier  Regional  Managers  fiom  viewing  diw  screen 
(middle  section  of  the  window),  and  c)  to  disconnect  observers  (right  section  of  the  screen). 
Due  to  tedinical  difficulties  w^  SvpaCuA  (which  does  not  permu  execution  of  desk 
accessory  moiu  entries  under  the  A^le  menu),  we  were  unable  to  kqdement 
progranminginthis  window  in  the  way  that  it  was  intended.  Imnead,  a  custom  menubar 
was  imptemented  which  conristed  cnty  of  the  ^iple  menu  (iriiidi  controb  access  to  desk 
accessories).  Umbuktu  access  wuthm  available  through  the  desk  accessory  (whidt  is  the 
way  in  which  it  is  normally  involGed). 


urr^nnLiiuir^iziu 


O  AllowSd^^^  AHowad 


- 

10  iMOonnoci 


Diatrflwied  Computer  Sofiported  Tcmi  Work 

hve64 


Distributed  Computer  Supported  Team  Work 

Page  65 


Purpose;  The  project  summary  window  fills  the  lower  portion  of  the  screen  and  contains  summary 
budget  informati(Hi  about  personnel,  equipment,  materials  &  supplies,  travel,  and 
subrantractors  line  items  Qcft  portion  of  the  window)  and  general  infcHTnaticm  about  the 
project  in  a  scrolling  field  (right  portion  of  the  window).  Transparent  butums  superimposed 
over  the  budget  line  item  names  provide  access  to  the  appropriate  detailed  spreadsheet  data. 
In  addition,  a  "Display  Classified  Infcntnation  for  Project"  button  appearing  under  the 
scrolling  field  controls  access  to  classified  infonnatitxi  about  the  project  (which  appears  in  a 
field  which  opaquely  covers  the  general  information  field).  The  classified  information  was 
intended  to  be  accessible  only  if  the  "CM>servers>Noc  Allowed"  option  was  selected  in  the 
communicaticMi  window. 

Script  for  Button  "Display  Classified  Information  for  Project" 

on  mouseUp 
set  the  cursor  to  4 

if  the  hilite  of  cd  button  "Allowed"  of  cd  "Comm"  of  -i 
window  "C^ommunications"  is  true  then 
show  cd  field  id  185 
bringFront 
wait  4  seconds 
hide  cd  field  id  185 
exit  mouseUp 
end  if 

show  cd  button  "Hide  Classified  Information  for  Project" 
show  cd  field  "Qassified  Geninfo" 
set  the  cursor  to  1 
end  mouseUp 


Script  for  "Budget  Line  Item"  Button  (Personnel  Example) 
on  mouseUp 

open  cd  "Personnel"  of  window  "Project  1" 

global  pal 

put  pal  +  1  into  pal 

trap 

end  mouseUp 


Window;  Budget  Itemization;  (Personnel  (Tard) 


Purpose:  This  window  ccmtains  the  cards  detailing  the  ^neadsheet  infonnation  for  each  of  the  five  line 
items  sumn'tarized  in  the  project  summary  win^w.  Managers  may  type  in  entries  in  either 
the  "Revised"  or  "%  Cut"  column.  The  {xogram  calculates  the  appropriate  corresponding 
respective  entry.  The  total  revisions  and  percentage  cut  of  the  initial  budget  is  summarized  in 
die  last  line  of  the  qneadsheet  and  die  changes  are  then  reflected  in  the  appropriate  location  in 
the  "Project  Summ^  Window". 


DiflaAnied  Conqntcr  S^iponod  Tom  Walk 


Budget  Itemization:  Personnel 


Lin*  ItMn 

Mttol 

RevteM 

S  Cut 

Pro^amincrs  (4) 

140 

140 

0 

Pro^ramnwrs  (4  #  iSO  tima) 

60 

60 

o 

Systwn  Analysts  (3) 

13S 

135 

0 

L««d  Analyst  (1) 

55 

55 

0 

ClwioaKi) 

20 

20 

0 

Ckrteals  (2  S  .50  tlma) 

20 

20 

0 

Ckrkal  Assistants  (2  9  .50  tima) 

16 

16 

0 

Clarical  Tamparary  (1) 

24 

24 

0 

Ovartima  allocation 

20 

20 

0 

_ _ 

- ■■■■ 

_ 

Tetals 

500 

400 

2 

(SSov  Cut  PrlThie^  (U»e»  All  Cit»| 


Script  for  Background  Button  "Show  Cut  Priorities" 

(MimouseUp 
set  the  cursor  to  4 

get  last  word  of  background  field  "Item"  of  window  ’’Project  1 " 
open  cd  it  of  window  "Priorities’’ 
set  the  cursor  to  1 
endtnouseUp 


Script  for  Background  Button  "Undo  All  Cuts" 

on  mouseUp 
tr^ 

set  the  cursor  to  4 

alobal  P1JP24>3J»44*5J»64^,P8J>9 
if  card  field  ’liiie2b"  is  not  empty  dien 
put  card  field  ”Line2b''  into  cud  field  ’'Line2c" 
put  ’’0"  into  card  field  "Line2d’’ 
end  if 

if  card  field  ’lineSb”  is  not  en^ty  then 
put  card  field  "lineSb"  into  ct^  field  ’’Line3c" 
put  ’’0"  into  card  field  "LineSd" 

^if 

if  card  field  1ine4b’'  is  not  empty  then 
put  card  fidd  ’line4b'’  into  cud  field  ’’Line4c'’ 
put  "0"  into  card  fidd  ’’Line4d’’ 
end  if 

if  card  field  ’lineSb"  is  not  empty  tfien 
put  card  fidd  ’IJneSb"  into  cira  field  "LineSc" 
put  "0"  into  card  field  "LineSd" 
end  if 

if  card  field  "Linetib"  is  not  empty  then 


Diltribuied  Computer  Supported  TamiiiW^ 


put  card  field  **Liiie6b"  into  caid  field  "Unefic" 
put  "0"  into  card  fidd  1ine6d" 
end  if 

if  card  field  1ine7b"  is  not  empty  then 
put  card  field  UneTb"  into  ciud  field  "Line7c” 
put  "0"  into  card  field  "Line7d" 
end  if 

if  card  field  lineSb"  is  not  empty  dien 
put  cad  fidd  lineSb”  into  cm  field  lineSc" 
put  ”0”  into  card  field  "LineSd" 
e^if 

if  card  field  "Line9b"  is  not  enq)ty  dien 
put  card  fidd  ”Line9b"  into  cad  field  *lJne9c‘' 
put  "0"  into  card  fidd  UneM" 

^if 

if  card  field  linelOb"  is  not  enq)ty  dien 
put  caid  field  "LinelOb"  into  ct^  field  "LinelOc" 
put  "0”  into  card  field  "LinelOd" 
e^if 

send  mouseUp  to  card  button  "Revise"  this  card 
end  mouseUp 


Sample  Script  for  entries  in  the  ’’Revised’*  field  cells 

Purpose:  The  first  part  of  this  script  (on  closeHdd)  checks  to  make  sure  tha  any  change  in  the  revised 
field  does  not  excMd  the  initial  amoum  budgeted  for  that  hem.  If  it  does,  a  warning  is 
fiashed  (by  showing  a  hidden  field  "Bad  Entry!")  and  the  entry  is  chan^  back  «>  the  initial 
amount  After  that  correction,  or  if  the  entry  is  a  valid  one,  then  die  scrmt  for  die  card  button 
"Revise"  is  executed.  The  second  portion  of  the  script  (on  retuinlnBeld)  sends  a  tabKey 
whenever  the  return  key  is  pressed  (which  dien  advances  the  cursor  to  the  next  valid  field  in 
die  column). 

oncloseField 

if  cd  field  "Line2c"  >  cd  field  "Line2b"  then 
show  background  field  "Bad  oitryl" 
wait  for  2  seconds 
hide  backj^ound  field  "Bad  entiyl" 
put  cd  Md  "Line2b"  into  cd  field  "Line2c" 
select  text  of  cd  field  "Line2c" 
mdif 

put  die  round  of  (((cd  field  "Line2b"  -  od  fidd  "Line2c")/(od 
field  "Line2b"))*100)  into  cd  field  "Line2d" 
acaid  mouseUp  to  od  button  "Revise" 
endcloseField 

on  retumlnField 
sendtabKcty 
endretumln^ld 


Sample  Script  for  entries  in  the  ”%  Cut"  fMd  odis 

Purpose:  The  first  pan  of  this  script  (on  closd^ld)diedcsio  moke  sure  diet  the  percentage  cut  entered 
does  not  exceed  100%.  If  it  does,  a  warning  is  flashed  (by  showing  a  hidden  fidd  "Bad 
Eittiy2")  and  the  entty  is  changed  back  to  0%.  Afterthatoanection,orifdieeninrisavalid 
one  (between  0>100%),  then  me  scii^  fir  die  cttd  batten  Iteviae”  is  executed.  Ihe  second 


portion  of  the  script  (on  retumInField)  sends  •  ttUCey  whenever  die  return  key  is  |»essed 
(which  then  advances  the  cursor  to  the  next  valid  field  m  the  ctdimin). 

on  closeField 

if  cd  field  "Liiie2d"  >  "100"  then 
show  background  field  "Bad  entry!" 
waitfQr2sec(xids 
hide  background  field  "Bad  entry!" 
put  "0"  into  cd  field  "Line!d" 
select  text  of  cd  field  "Line!d" 
end  if 

put  the  round  of  (cd  field  "Line!b"  •  (cd  field  "Line2b"  *  -■ 

(cd  field  "Luie!d"/100)))  into  cd  field  "Line!c" 
send  mouseUp  to  cd  button  "Revise" 
end  closeField 

on  retumInField 
sendtabKey 
end  retumInReld 


"Revise"  Button  Script 

Purpose:  This  button  updates  the  impropriate  totals  for  the  revised  budget  and  inserts  it  in  the 

q^xopriate  spot  in  the  latt  line  of  the  qxeadsheet  and  also  in  the  aimropriate  locstkn  in  the 
project  sumtnary  window.  The  script  dien  executes  die  "Budget  Updak"  button. 

on  mouseUp 
set  the  cursor  to  4 

global  P1J*2J»3JP4J»54*64»7J*8J*9 
put  card  field  "Liiie!c"  into  PI 
pot  card  field  "Line3c"  into  P! 
put  card  field  "Line4c"  into  P3 
put  card  field  "LineSc"  into  P4 
put  card  field  "Linedc"  into  P5 
put  card  field  "lineTc"  into  P6 
put  card  field  "LineSc"  into  P7 
put  card  field  ”line9c"  into  P8 
put  card  field  XinelOc"  into  P9 

put  (P1+P2+P3+P4+P5+P6+P7+P8+P9)  into  card  field  "RToial" 

put  card  field  "RTotal"  into  card  field  "lW2c"  of 

cd  "Summary  1"  of  window  id  10! 

send  closdF^ld  to  card  field  "Une!c"  of  -« 

cd  "Summary  1"  of  window  id  10! 

if  cd  field  "Piotal"  is  "0"  then 

^t  "0"  into  od  field  "Linel!d" 

put  round  (((cd  field  "PTotal"-od  field  1Uoiri">bd  field  "IToiriT100)-i 
W>cd  field  "Unel2d" 
end  if 

send  mouseUp  to  background  button  "Budget  Update" 
if  the  visible  «  window  "Revirod  Allocation"  is  arue  then 
send  clostf^eld  to  cd  field  "Revised  Region  2"  of  cd  "Budget"  of-i 
window  "Budget  AUocatkns" 
e^if 

end  mouseUp 
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Script  for  Background  Button  ''Budget  Update" 

Purpose:  This  button  totals  up  the  updated  budget  numbers  shown  for  each  project  in  die  project 

diiecttiry  window  updates  the  region  total  shown  in  the  "Budget  Allocations”  window. 

onmouseUp 

put  ((cd  Field  "Rtotal"  of  cd  "Summary  1"  of  window  id  102)+-i 
(cd  Field  "Rtotal"  of  cd  "Summary  2"  of  window  id  103>t— i 
(cd  Field  "Rtotal"  cd  "Summary  3"  of  window  id  104)-»— i 

(cd  Field  "Rtotal"  of  cd  "Summary  4"  of  window  id  lOS)-!— • 

(cd  Held  "Rtotal"  of  cd  "Summary  S"  of  window  id  106))  into-i 
cd  field  "Revised  Region  1"  of  cd  "Budget"  of  window  "Bud^t  Allocations” 
send  closeField  to  cd  field  "Revised  Region  1"  cd  ”Budget”-i 

of  window  "Budget  Allocations” 
end  mouseUp 


Window;  Priorities  (Personnel  Card)  | 


Purpose:  The  five  cards  in  this  window  coneqiond  to  each  of  die  budget  line  items  and  provide 
guidelines  to  the  regional  managers  as  to  the  cut  priorities  generally  set  forth  by  die 
organization  (unless  otherwise  indicated).  This  window  is  invok^  by  the  user  by  pressing 
the  "Show  Cut  Priorities"  button  in  the  Budget  Itemization  windows. 


Ptruonnef  PrioritiM 

1.  Full  tima  protassional  amployees 

2.  Full  tima  tachnical  amployMS 

3.  Part  timaprofoasionalamployaes  shared  with  othar  projects 

4.  Full  time  clericai  workers 

5.  Part  time  technical  employeea 

6.  Part  time  clerical  workars 

7.  Consultants 

8.  Temporary  woiksrs 

9.  Overtime 
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Appendix  D-  Screen  1 

Region  2  Sample  Task  Session  Screen  Displays 
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Appendix  D-  Screen  2 
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Appendix  D-  Screen  3 
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Appendix  D-  Screen  4 
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Omega  Budget  Allocations,  90-91 

(In  Thousands  of  Dollars) 
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Appendix  D-  Screen  6 
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